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Preface 


Air  Force  Systems  Command  terminated  the  effort  which  this  document 
describes  before  the  effort  reached  its  logical  conclusion.  This  report 
is  incomplete  but  was  published  in  the  interest  of  capturing  and  dissem- 
inating the  computer  security  technology  that  was  available  at  the  time 
of  the  termination. 

This  report  was  to  precisely  define  the  functional  characteristics 
of  a security  kernel  for  the  Multics  computer  system.  The  report  is 
thorough  in  its  treatment  of  the  functional  characteristics  that  are 
addressed.  However,  the  report  is  incomplete.  Many  areas  of  the  design 
are  omitted,  such  as  external  I/O,  reconfiguration,  initialization, 
"trusted  subject"  interfaces,  and  message  segments.  Specific  design 
decisions  are  avoided  in  certain  areas}  particularly  various  instances 
of  the  "finite  resource  problem".  Most  of  these  omissions  are  explic- 
itly acknowledged  in  the  report.  The  termination  of  this  effort  did  not 
allow  the  completion  of  the  security  kernel  functional  design. 


This  report  has  benefited  from  the  ideas,  comments,  and 
criticisms  of  many  people.  A long  history  of  conversations 
between  the  author  and  Andre  Bensoussan  has  been  very  helpful. 
Some  of  these  conversations  were  also  joined  by  Michael 
Schroeder.  The  author  is  particularly  grateful  to  Douglas  Hunt 
who  reviewed  early  drafts  of  the  specifications  and  contributed 
many  useful  suggestions.  Thanks  are  also  due  Richard  Feiertag 
wno  helped  to  resolve  a number  of  problems  regarding  the 
specification  technique.  Bernard  Greenberg  was  relied  upon  many 
times  for  his  expert  knowledge  of  Multics. 
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CHAPTER  I 


INTRODUCTION 


A security  kernel  is  a collection  of  hardware  and  software 
mechanisms  within  a computer  system  that  together  control  access 
to  information  according  to  prescribed  policies.  This  report 
presents  a preliminary  formal  top-level  specification  of  a 
security  kernel  designed  to  support  Multics,  a sophisticated 
general-purpose  computer  system  produced  by  Honeywell.  The 
specifications  describe  the  input/output  behavior  of  the  security 
kernel  and,  thereby,  provide  a suitable  basis  for  formal 
valiaation  of  this  behavior  with  respect  to  desired  security 
properties. 

Tne  top-level  specification  plays  a key  role  in  the  development 
of  the  security  kernel.  The  top-level  specification  must  be 
proven  to  correspond  to  a mathematical  model  of  secure  computer 
operation.  The  model  chosen  for  the  Multics  security  kernel  is 
specifically  devised  to  meet  the  requirements  of  the  military 
security  system  [BL] . A technique  for  proving  correspondence  of 
this  model  to  specifications  of  the  kind  presented  in  this  report 
has  been  demonstrated  [Mil] . Once  the  correspondence  of  the 
top-level  specification  to  the  model  has  been  established,  the 
moael  need  no  longer  be  explicitly  considered. 

A general  methodology  for  the  design,  implementation  and  proof  of 
software  systems  has  been  developed  at  Stanford  Research 
Institute  [RLNSJ.  It  is  believed  that  this  methodology  can  be 
applied  to  the  Multics  security  kernel,  thus  making  possible  a 
proof  that  the  security  kernel  implementation,  in  fact, 
corresponds  to  the  top-level  specification. 

Background 

Tne  Air  Force  has  been  studying  the  problem  of  providing  a 
certifiably  secure  multilevel  system  for  several  years.  In  1970, 
the  Air  Force  Data  Services  Center  (AFDSC ) requested  the 
Electronic  Systems  Division  (E3D)  to  support  development  of  an 
open  multilevel  system  for  the  AFDSC  Honeywell  635  systems.  The 
resulting  studies  pointed  out  the  severity  of  the  problem  and  led 
to  the  formation  of  a computer  security  technology  planning  study 
panel.  The  panel's  report  [And]  described  the  fundamental 
problems  ano  delineated  a program  to  develop  the  desired  system. 
The  panel  recommended  that  the  technical  approach  to  the  problem 
be  "to  start  with  a statement  of  an  ideal  system,  a model,  and  to 
refine  and  move  the  statement  through  various  levels  of  design 
into  the  mechanism  that  implements  the  model  system". 

The  basic  component  of  the  ideal  system  was  also  identified  by 
this  panel.  This  component  is  known  as  the  Reference  Monitor,  an 
abstract  mechanism  that  controls  access  of  subjects  (active 
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system  elements)  to  objects  (units 
computer  system  according  to  the 
system.  Tnree  requirements  were 
Monitor : 


of  information)  within  the 
rules  of  the  military  security 
recognized  for  a Reference 


a.  Complete  Mediation  - the  mechanism  must  mediate  every 
access  of  a subject  to  an  object. 


b.  Isolation  - the  mechanism  and  its  data  bases  must  be 
protectea  from  unauthorized  alteration. 


c.  Verifiability  - the  mechanism  must  be  small,  simple, 
and  understandable  so  that  it  can  be  completely  tested 
and  verified  (certified)  to  perform  its  functions 
correctly. 


The  mechanism  that  implements  the  Reference  Monitor  in  a 
particular  computer  system  has  been  termed  the  security  kernel. 
Much  subsequent  work  has  been  devoted  to  identifying  the 
characteristics  of  a security  kernel  and  to  exploring  the 
technology  involved  in  producing  a security  kernel  for  a suitable 
computer  system. 


A major  goal  of  the  project  is  the  development  of  a security 
kernel  for  a large  resource  sharing  system.  The  system  chosen 
tor  this  effort  is  Multics.  There  are  two  reasons  for  this 
choice.  First,  the  hardware  base  of  the  Multics  system,  the 
Honeywell  Series  6U  (Level  6b)  computer,  has  been  identified  as 
best  suited  of  all  conmonly  available  large  computer  systems  for 
the  support  of  a security  kernel  (Smij . Second,  the  Multics 
system  architecture  was  conceived  and  developed  with  access 
control  requirements  specifically  in  mind. 

One  project,  now  completed,  involved  the  design  and  production  of 
a Multics  system  capable  of  supporting  a two-level  (Secret  and 
Top  Secret)  environment  for  the  Air  Force  Data  Services  Center 
(WBGHKSJ . This  system  implements  security  controls  based  on  the 
military  access  rules,  but  the  correctness  of  these  controls  has 
not  been  formally  verified. 

Design  of  a security  kernel  for  Multics  was  started  as  a joint 
effort  between  personnel  from  ESD,  the  MITRE  Corporation,  the 
Massachusetts  Institute  of  Technology,  and  Honeywell  Information 
Systems.  The  first  step  in  producing  a formal  top-level 
specification  was  undertaken  by  a team  from  MITRE  ( SB B ] . 

Nature  of_the  Multics  Security  Kernel 

To  a first  approximation,  the  security  kernel  can  be  viewed  as  a 
primitive  nucleus  of  the  current  Multics  supervisor.  The 
supervisor  is  not  replaced  by  the  kernel;  rather  it  is  built  on 
top  of  the  kernel.  Tnis  kernel-supervisor  combination  must  be 
capable  of  supporting  the  Multics  operating  system  with  little 
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change  to  the  user  interface. 

The  kernel  must  contain  all  mechanisms  that  are 
security-sensitive,  i.e.,  mechanisms  that  must  be  proven  to 
perform  properly  in  order  to  guarantee  secure  behavior.  In  this 
case,  "secure  behavior"  is  defined  by  the  mathematical  model. 
Certain  access  control  policies  now  enforced  by  the  Multics 
supervisor,  but  not  aaaressed  by  the  model,  need  not  be  enforced 
by  the  kernel.  These  policies  can  continue  to  be  enforced  by  an 
unproven  supervisor. 

It  is  essential  that  the  size  of  the  security  kernel  be  kept  to  a 
minimum  in  order  to  facilitate  its  specification  and  proof.  The 
present  Multics  supervisor  contains  many  examples  of  the 
interweaving  of  security-sensitive  functions  with  other  functions 
of  no  security  importance.  The  security-sensitive  functions  must 
be  extricated  ana  isolated  in  the  kernel.  The  most  notable 
example  of  this  philosophy  is  provided  by  the  absence  of  the 
Multics  directory  hierarcny  from  the  kernel  specifications 
presentea  in  this  report.  As  proposed  by  Andre  Bensoussan  [Ben], 
tne  management  of  directories  can  be  accomplished  outside  the 
kernel.  Thus,  the  kernel  has  no  knowledge  of  directories. 

Isolation  of  the  kernel  is  accomplished  by  two  different  means. 
A major  portion  of  the  kernel  resides  in  a protected  subsystem 
whose  execution  is  distributed  across  all  processes.  Protection 
is  provided  Dy  the  hardware  ring  mechanism  of  the  Multics 
processor  [SS].  This  portion  of  the  kernel  is  akin  to  the 
current  Multics  ring  u and  ring  1 supervisor.  For  implementation 
reasons,  it  is  convenient  to  isolate  certain  other  kernel 
functions  in  single  processes  rather  than  attempting  to 
distribute  tnese  functions  across  all  processes.  These  kernel 
processes  closely  resemble  some  of  the  system  daemon  processes  of 
current  Multics. 


Kernel  processes,  like  ordinary  processes,  are  supported  by  the 
inner  ring  portion  of  the  kernel.  However,  the  inner  ring 
portion  of  the  kernel  provides  certain  special  interfaces  that 
are  available  only  to  kernel  processes.  These  interfaces  are 
internal  to  the  kernel  and  therefore  are  not  a part  of  the 
top-level  specification.  A few  of  these  special  interfaces, 
however,  are  included  in  this  report  simply  to  aid  in  the 
exposition  of  overall  kernel  operation.  External  interfaces 
provided  by  kernel  processes  are  a part  of  the  top-level 
specification. 

Plan  of this  Report 

Before  proceeding  to  the  presentation  of  the  top-level  security 
kernel  specification,  chapters  2 and  3 first  introduce  some 
prerequisite  material.  In  chapter  2,  certain  aspects  of  the 
relationship  among  the  mathematical  model,  the  formal 
specifications,  and  the  practical  constraints  imposed  by  real 
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computer  systems  are  explorea.  In  chapter  3,  the  specification 
technique  is  aescribea.  Chapter  4 provides  a brief  overview  of 
tne  kernel  specifications.  The  remaining  chapters  contain  the 
actual  formal  specifications  and  accompanying  prose  descriptions. 
A familiarity  with  the  Multics  system  is  assumed  throughout. 

The  top-level  specification  presented  in  this  report  does  not 
specify  interfaces  to  the  kernel  I/O  system.  Specification  of 
these  interfaces  is  awaiting  evaluation  of  the  results  of  a 
separate  I/O  stuay  [Hon] . Operator  interfaces  to  perform 
hardware  reconfiguration  have  also  been  temporarily  omitted. 

I 
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CHAPTER  II 


RECONCILING  THE  MODEL  WITH  A REAL  COMPUTER  SYSTEM 

Two  funaamental  requirements  exist  for  the  security  kernel 
described  in  tnis  report:  (1)  it  must  satisfy  the  mathematical 
model,  and  (2)  it  must  be  capable  of  supporting  Multics  in  a 
reasonaoly  compatible  and  efficient  manner.  As  might  be 
expecteo,  these  two  requirements  are  not  always  in  harmony. 
Moreover,  consider ations  that  have  no  relevance  in  the  simplistic 
world  of  the  model  can  be  of  great  concern  in  the  complicated 
world  of  a real  computer  system.  This  chapter  first  attempts  to 
sketcn  the  relationship  between  the  model  and  the  security 
kernel.  Knowledge  of  the  model  is  assumed.  Following  this, 
certain  general  problems  that  real  systems  must  face  in 
attempting  to  meet  the  model  are  discussed. 

Kelationsnip  of  the  Model  to  the  Kernel 

Tne  principal  components  of  the  mathematical  model  are  a set  of 
subjects  ano  a set  of  objects.  A subject  is  a surrogate  for  a 
person,  in  this  case,  a computer  system  user.  The  security 
kernel  employs  the  Multics  process  abstraction  to  represent  the 
notion  of  a subject.  An  object  is  an  information  container  which 
may  take  any  number  of  different  forms  within  the  computer 
system.  For  example,  segments  are  objects  supported  by  the 
Multics  kernel. 

Tne  model  embodies  two  non-oiscretionary  access  control  policies 
known  as  security  and  integrity.  The  integrity  policy  was  not  a 
feature  of  the  original  mooel,  but  has  since  been  adopted  [Bib]. 
Each  suoject  and  each  ODject  possess  both  a security  level  and  an 
integrity  level.  For  simplicitly,  both  of  these  attributes  are 
combined  in  tne  top-level  specification  into  a single  attribute 
called  an  access  level.  The  relationship  between  a subject 
access  level  ano  an  object  access  level  determines  whether  the 
subject  can  read  ano/or  write  the  object. 

An  additional  attribute,  called  the  visibility  access  level,  is 
associated  with  certain  objects.  Detection  of  the  existence  of 
such  objects  is  controlled  by  this  attribute  rather  than  the 
regular  access  level.  The  visibility  access  level  is  not  a 
feature  of  the  mathematical  model.  However,  it  has  been 
introouceo  here  in  order  to  explicitly  address  the  problem  of 
object  detection.  In  certain  situations  it  is  appropriate  for  a 
process  to  oe  able  to  detect  the  existence  of  an  object  and  yet 
have  no  access  to  the  contents  of  the  object.  Therefore,  a 
distinct  access  level  is  needed  to  control  object  detection.  In 
most  cases,  the  visibility  access  level  of  an  object  will  equal 
the  access  level  of  its  creator.  In  addition  to  detection  of 
existence,  the  visibility  access  level  is  also  the  logical  choice 
for  controlling  object  deletion  and  the  observation  of  permanent 
object  attributes  specified  at  creation  time. 
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In  addition  to  security  and  integrity,  the  model  also  describes  a 
form  of  discretionary  access  control.  There  exists  an  access 
matrix,  each  entry  of  which  describes  the  mode  of  access  that  a 
given  subject  may  have  for  a given  object.  This  access  mode 
cannot  exceed  that  dictatea  by  tne  non-discretionary  policies. 
Aside  from  this  restriction,  however,  the  access  matrix  may  be 
arbitrarily  modified.  Thus,  a process  can  always  grant  itself 
access  to  an  object  so  long  as  this  is  permitted  by  the 
non-discretionary  access  controls.  The  standard  discretionary 
access  control  mechanism  now  provided  by  Multics,  i.e.,  the 
access  control  list  (ACL) , is  more  restrictive  than  the  model 
requires.  Hence,  ACLs  need  not  be  implemented  by  the  kernel. 
Instead,  the  kernel  maintains  a simpler  representation  of  the 
access  matrix  for  segment  objects.  For  all  other  objects,  the 
access  matrix  is  degenerate  and  static,  i.e.,  all  subjects  have 
full  discretionary  access  to  all  non-segment  objects.  Any  finer 
control  of  access  to  these  objects  is  provided  by  the  supervisor. 

Trusted  Processes 

Tnere  exists  a collection  of  functions  needed  within  the  computer 
system  environment  that  have  no  direct  counterpart  within  the 
mathematical  model.  Examples  of  such  functions  include: 

1.  changing  tne  access  levels  of  serially  reusable  resources, 
e.g.  peripheral  devices; 

2.  accepting  user  logins; 


3.  repairing  damaged  kernel  data  bases  after  a system  failure; 

4.  changing  the  access  level  of  a user  segment. 

These  operations  are  clearly  critical  to  security,  yet  they  are 
outside  the  scope  of  the  model.  To  preserve  security,  these 
functions  must  only  be  performed  by  trusted  persons  using 
verified  programs.  Note,  however,  that  the  verification  of  such 
programs  does  not  entail  proving  a correspondence  to  the  model. 
Rather,  it  requires  proving  that  each  program  performs  its 
specific  task  correctly  and  without  unwanted  side-effects. 


It  seems  helpful  to  draw  a distinction  between  the  basic  security 
kernel,  which  enforces  the  rules  of  the  model,  and  this  second 
collection  of  "trusted"  functions  that  operate  outside  the  realm 
of  the  model.  In  terms  of  an  implementation,  the  trusted 
functions  are,  to  a large  extent,  supported  by  the  basic  security 
kernel.  In  fact,  many  ordinary  kernel  functions  can  also  operate 
on  behalf  of  trusted  functions.  The  only  difference  is  that  in 
the  trustee  mode,  kernel  functions  are  not  subject  to  the  usual 
security  restrictions. 


Trusted  functions  must  interface  directly  to  trusted  users.  No 
uncertified  programs  can  be  interposed  between  a trusted  user  and 
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a trusted  function  because  this  could  result  in  misuse  of  trusted 
functions  in  a manner  not  intended  by  and  not  apparent  to  the 
trusteo  user.  This  requirement  for  airect  user  interaction  shows 
a clear  contrast  between  security  kernel  functions  and  trusted 
functions.  Security  kernel  functions  are  primitive  and  far 
removed  from  the  user  interaction  level  whereas  trusted 
functions,  by  necessity,  cannot  depend  on  any  higher  level 
functions . 

Due  to  the  different  nature  of  trusted  functions  and  the 
different  requirements  for  verification,  specifications  for 
trusted  functions  are  not  provided  in  this  report.  However, 
because  trusted  functions  can  make  use  of  more  primitive  kernel 
functions,  the  ability  of  kernel  functions  to  operate  in  either  a 
trusted  or  untrustea  mode  is  explicitly  shown.  The  method  by 
wnich  tne  kernel  is  able  to  discriminate  between  trusted  and 
untrustea  use  of  functions  is  by  means  of  a special  trusted 
process  attribute.  This  attribute  is  taken  into  consideration  in 
each  access  control  aecision. 

A simple  scheme  for  handling  trusted  processes  would  be  to  allow 
trustee  processes  to  bypass  entirely  normal  security 
restrictions.  Tnis  scheme,  however,  has  certain  disadvantages. 
Tne  examples  of  trusted  functions  given  previously  included 
resource  management,  error  recovery,  and  other  operations  that 
might  best  be  delegated  to  a small  number  of  trusted  persons. 
Security  matters  would  be  the  principal  concern  of  these  persons, 
called  security  officers,  who  must  necessarily  be  trustworthy  to 
the  maximum  system  access  level.  However,  there  exists  another 
class  of  trusted  operations  that  are  regularly  required  by 
orainary  users.  Insisting  that  all  such  operations  be  performed 
by  a security  officer  places  a heavy  burden  on  the  security 
officer  and  inconveniences  the  user. 


A aiffenent  approach  to  this  problem  is  taken  here.  An  access 
level  is  still  associatea  with  each  trusted  process.  This  access 
level  aetermines  the  degree  to  which  the  process  can  be  trusted. 
Thus,  any  user  can  be  provided  with  a trusted  process  capable  of 
performing  certain  trusted  functions,  but  still  properly 
restricted  by  tne  user's  access  level.  This  agrees  with  the 
fundamental  assumption  that  each  user  is  trustworthy  to  his  own 
access  level.  When  executing  unverified  programs,  a user  cannot 
be  trusted  and  therefore  must  be  forced  to  abide  by  all  rules  of 
tne  model.  However,  when  confined  to  a trusted  process  capable 
of  executing  only  trusteo  programs,  certain  restrictions  can  be 
removed.  In  particular,  a trusted  process  is  permitted  to  write 
objects  of  a lower  security  level  and  to  read  objects  of  a lower 
integrity  level. 

Time  Channels 


With  the  given  model,  the  ability  of  the  security  kernel  to 
prevent  unauthorized  disclosure  or  modification  of  information 
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depends  upon  the  assumption  that  information  can  only  be  passed 
trom  one  subject  to  another  through  some  commonly  accessible 
object.  Such  information  channels  between  subjects  are  called 
storage  channels.  There  exists,  however,  a second  class  of 
information  channels,  called  time  channels,  which  are  not 
accountea  tor  by  the  model.  If,  for  example,  the  time  required 
tor  a subject  SI  to  access  object  01  can  be  influenced  by  the 
aecision  of  subject  S2  to  access  or  not  access  an  object  02,  then 
a time  channel  exists.  In  terms  of  real  systems,  time  channels 
almost  always  exist  when  a physical  resource  (e.g.,  a processor 
or  memory)  is  time-multiplexed  among  users.  The  control  or 
elimination  of  time  channels  is  generally  recognized  to  be  a 
aifficult  problem,  the  solution  to  which  would  appear  to  impose 
an  unacceptable  performance  degradation  on  any  real  system. 
There  is  perhaps  some  consolation  in  the  fact  that,  in  comparison 
to  storage  channels,  time  channels  tend  to  be  low  in  bandwidth 
ana  difficult  to  use.  In  any  case,  prevention  of  unauthorized 
disclosure  or  modification  of  information  through  time  channels 
is  not  a formal  requirement  for  the  kernel-basea  Multics. 

The  Sharea  Finite  Resource  Problem 

Tne  mathematical  moael,  being  an  abstract  system,  is  not 
constrainea  by  physical  limitations.  The  number  of  abstract 
objects,  for  example,  can  be  arbitrarily  large.  The  situation  in 
real  computer  systems  is  quite  different,  of  course.  Physical 
resources  such  as  seconaary  storage,  main  memory,  I/O  channels, 
etc.  exist  in  limitea  sizes  and  quantities  that  must  be  shared 
among  users  ot  different  access  levels.  A general  problem  arises 
when  a user  requests  a particular  resource  that  is  in  use,  filled 
up,  or  otherwise  unavailable  aue  to  the  activities  of  other 
users.  It  the  user  requesting  the  resource  can  learn  that  it  is 
unavailable,  then  an  uncontrolled  information  path  exists. 

A variety  of  solutions  to  this  problem  are  known.  Two  general 
approaches  are  preallocation  and  automatic  time-multiplexing.  In 
tne  case  of  preallocation,  resources  are  statically  partitioned 
among  tne  various  access  levels.  This,  the  information  path 
aescribea  above  can  only  oe  exploited  by  users  of  the  same  access 
level  ana  therefore  is  harmless.  In  the  case  of  automatic 
time-multiplexing,  the  user  is  never  refused  a resource,  but 
rather  is  forced  to  wait  (a  presumably  short  length  of  time)  for 
one  to  become  available.  As  mentioned  earlier,  time-multiplexing 
inevitably  produces  time  channels.  A third  approach  is  to  allow 
a trusted  process  to  manage  a given  shared  resource.  Note, 
nowever , that  such  a trusted  process  cannot  simply  respond  to 
requests  for  resources  from  untrusted  processes.  This  would  only 
succeed  in  reproducing  the  very  same  information  path  described 
above  with  the  trusted  process  serving  as  part  of  the  mechanism. 
Therefore,  tne  trusted  process  must  be  externally  controlled, 
e.g.  by  an  operator  or  aaministr ator , and  user  requests  for 
resources  must  be  communicated  outside  the  system. 


mm* 


The  problem  of  sharing  a finite  resource  among  multiple  access 
levels  will  be  seen  to  recur  throughout  the  top-level 
specification.  In  principle,  any  of  the  three  techniques 
described  above  can  be  applied  to  any  instances  of  this  problem. 
In  practice,  however,  these  approaches  may  have  undesirable,  if 
not  intolerable,  operational  characteristics,  or  may  require  an 
excessive  amount  of  mechanism  to  implement.  For  a number  of 
cases  of  the  shared  finite  resource  problem,  acceptable  solutions 
have  not  yet  been  devised.  For  these  cases,  the  top-level 
specification  circumvents  the  problem  by  essentially  treating  the 
resource  involved  as  infinite  in  size  or  quantity.  These  cases 
are  identifieo  in  the  top-level  specification  description. 
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CHAPTER  III 


SPECIFICATION  TECHNIQUE 

The  specification  technique  used  in  this  report  is  based  upon  a 
method  suggested  by  Parnas  [Par].  Although  Parnas  specifically 
addresses  the  "software  engineering"  problem,  the  technique  is 
not  restrictea  to  software  alone.  In  fact,  the  specifications 
presented  in  this  report  describe  aspects  of  the  security  kernel 
that  encompass  both  hardware  ana  software  mechanisms.  A notation 
is  employed  tnat  conforms  to  a formal  specification  and  assertion 
language  known  as  SPECIAL  that  was  developed  at  Stanford  Research 
Institute.  The  language  is  relatively  young  and  therefore  still 
evolving . 

In  this  chapter,  the  objectives  of  the  specification  technique 
are  first  examinea.  Next  some  basic  features  of  SPECIAL  are 
described  along  with  the  concept  of  an  abstract  machine 
interpreter . 

Specification  Ob j ect ives 

The  objective  of  the  specification  technique,  as  stated  by 
Parnas,  is  to  provide  a precise  specification  of  a program  (or, 
in  general,  an  abstract  machine)  without  revealing  too  much 
information.  In  particular,  a specification  should  supply  the 
information  needed  to  use  a program,  but  should  reveal  nothing 
about  the  internal  operation  of  the  program.  Thus,  a Parnas 
specification  can  be  viewed  as  an  input/output  characterization 
of  a "black  box". 

Avoidance  of  over-specification  is  the  fundamental  concept 
unaerlying  tne  specification  technique.  The  information  provided 
by  a specification  is  limited  to  that  which  is  externally 
ODservable.  Parnas,  however,  expresses  no  concern  for 
unaer-specif ication,  i.e.  providing  less  information  than  is 
externally  observaDle. 

For  the  purpose  of  proving  security  properties  of  a 
specification,  the  concerns  are  somewhat  different  from  those 
emphasized  by  Parnas.  Under-specification  cannot  be  tolerated. 
It  is  absolutely  essential  that  a specification  contain  all 
information  that  can  be  externally  observed.  Otherwise, 
information  paths  not  accounted  for  by  the  specifications  may 
exist  and  will  not  be  proven  secure.  On  the  other  hand, 
over-specification  is  only  of  secondary  concern.  At  worst, 
over-specification  may  introduce  irrelevant  information  that 
complicates  the  proof  of  the  specifications. 

Avoidance  of  under-specification  is  extremely  difficult  for  the 
current  Multics.  It  viewed  in  full  detail,  Multics  is  an 
entirely  ueterministic  system.  However,  this  view  is 
extraordinarily  complicated  because  it  includes  knowledge  of 
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hidden  mechanisms  (e.g.  paging).  At  tne  user  interface  level, 
these  hidden  mechanisms  can  be  ignored  for  the  most  part  without 
sacrificing  a deterministic  view  of  the  system.  However,  in  a 
few  instances,  the  effects  of  these  hidden  mechanisms  are 
detectable  at  tne  user  interface.  For  example,  a zero  page  is 
automatically  deallocated  at  the  time  it  is  selected  for  removal 
from  main  memory  and  this  deallocation  is  reflected  in  user 
observable  segment  attributes.  Such  behavior  cannot  be 
completely  specified  without  introducing  the  details  of  the 
paging  mecnanism.  It  seems  possible  to  write  a non-oeterministic 
specification  which  states  simply  that  a page  may  be  deallocated 
sometime  after  it  becomes  a zero  page.  Clearly,  however,  this  is 
a case  of  under-specification.  Moreover,  there  exists  an 
information  path  (of  the  storage  channel  variety)  not  accounted 
for  oy  tnis  specification. 

Two  approaches  are  apparent  for  dealing  with  those  "features"  of 
Multics  that  make  hidden  mechanisms  detectable.  One  approach  is 
to  provide  complete  specifications  that  fully  expose  the  hidden 
mechanisms.  Tnis  would  result  in  gross  complexity  that  would 
ninoer  proofs  of  security  properties.  Even  if  this  were  done, 
however,  it  would  only  lead  to  the  discovery  of  an  already 
ODvious  fact:  in  most  cases,  the  detectability  of  hidden 
mechanisms  produces  insecure  information  paths.  Therefore,  a 
second  approacn  has  been  adopted.  This  approach  requires 
changing  Multics  where  necessary  to  prevent  detection  of  hidden 
mechanisms.  One  can  then  provide  complete  specifications  that 
show  no  evidence  of  tnese  hidden  mechanisms. 

An  Introduction  to  SPECIAL 

The  following  description  is  intended  only  as  a very  brief 
overview  of  some  of  the  basic  features  of  SPECIAL.  For  a 
complete  description  of  the  language,  the  reader  is  referred  to 
tne  SPECIAL  reference  manual  (HR)  . The  language  of  the 
specifications  contained  in  this  report  corresponds  exactly  to 
SPECIAL  as  described  in  the  reference  manual. 

SPECIAL  allows  for  the  definition  of  abstract  data  objects  and 
operations  performed  upon  these  objects.  The  objects  ate 
represented  as  V-functions,  i.e.,  functions  that  return  a value. 
The  collection  of  V-functions  represents  the  state  of  the  system 
being  specified.  Operations  on  objects  are  represented  by 
O-functions.  O-functions  modify  the  values  of  V-functions  and 
thereby  change  the  state  of  the  system.  A third  class  of 
functions  is  that  of  OV-f unctions , i.e.,  functions  that  both 
change  tne  system  state  and  return  a value. 

A distinction  among  V-functions  is  that  they  can  be  either 
primitive  or  derived.  The  value  of  a derived  V-function  is 
simply  an  expression  in  terms  of  other  V-functions.  Only  the 
values  of  primitive  V-functions  can  be  changed  by  O-functions  and 
this  implicitly  changes  the  values  of  related  derived 


V-f unctions. 


A second  distinction  among  V-functions  is  that  they  can  be  either 
visible  or  hidden.  A visible  V-function  is  one  that  is  available 
to  the  outside  world.  A hidden  V-function  can  only  be  referenced 
from  within  other  functions.  By  convention,  the  names  of  all 
nidden  V-functions  contained  in  the  kernel  specification  begin 
with  the  prefix  "h_". 

An  individual  function  specification  comprises  several  different 
parts.  For  visible  functions,  the  first  part  is  always  a list  of 
exception  conditions,  i.e.,  conditions  under  which  the  function 
fails  to  operate  or  return  a value.  These  exceptions  apply  only 
when  a visible  function  is  referenced  from  the  outside  world, 
wnen  referenced  internally,  i.e.,  from  within  another  function, 
exceptions  are  ignored.  Similarly,  hidden  functions,  which  can 
only  oe  referenced  internally,  have  no  exceptions.  The  remaining 
parts  of  a function  specification  differ  for  V-functions  and 
O-functions.'  In  the  case  of  a V-function,  the  specification 
contains  either  an  initial  value  for  a primitive  V-function  or 
tne  cerivation  expression  for  a derived  V-function.  O-functions 
and  OV-functions  contain  a list  of  "effects"  that  describe 
changes  to  V-functions.  For  an  OV-function,  the  effects  also 
define  the  output  value.  The  order  of  effects  within  a given 
list  is  unimportant.  All  effects  occur  at  once,  i.e. 
instantaneously.  Within  an  effects  list,  references  are  made  to 
the  old  and  new  values  of  V-functions,  i.e.  the  values  before  and 
after  the  effects  have  occurred.  The  new  value  of  a V-function 
is  indicated  by  a single  quotation  mark  (’)  preceding  the 
v-function  name. 

Tne  entire  set  of  functions  which  constitute  the  top-level 
specification  are  divided  into  groups  called  modules.  The 
purpose  of  modules  is  to  allow  the  specifier  to  conveniently 
organize  a possibly  large  number  of  functions  into  small 
groupings  that  can  be  easily  understood.  The  modular ization 
serves  no  otner  purpose.  Often,  the  modules  may,  in  some  ways, 
correspond  to  actual  program  modules  in  a perceived 
implementation.  This,  however,  is  not  necessary. 

Function  references  between  modules  are  permitted.  A function  of 
one  module  can  observe  the  values  of  V-functions,  including 
hidden  V-functions,  of  any  other  module.  However,  V-functions 
can  only  be  directly  modified  by  0-  or  OV-functions  of  the  same 
mooule.  Therefore,  in  order  for  one  module  to  change  a 
V-function  of  another  mooule,  the  first  module  must  invoke  an  0- 
or  OV-function  of  the  second  module. 

The  specification  of  a module  is  divided  into  six  sections  as 
follows: 
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1.  TYPES 


This  section  defines  new  aata  types  which  supplement  the 
primitive  data  types  of  the  language. 

2.  DECLARATIONS 

Tnis  section  defines  variable  names  and  tneir  associated  data 
types. 

3.  PARAMETERS 

This  section  defines  named  constants  which,  in  SPECIAL,  are 
called  parameters. 


DEFINITIONS 


Tnis  section  allows  for  the  specification  of  macros. 


EXTERNALREFS 


This  section  oefines  all  external  functions  referenced  within  the 
mociule . 

0.  FUNCTIONS 

Tnis  section  contains  all  of  the  individual  function 
specifications  for  the  module. 


!££!?_ Abstract  Macnine  Interpr£ter 

The  purpose  of  the  top-level  specification  is  to  define  an 
abstract  machine  whose  behavior  represents  that  of  a Multics 
security  kernel  as  viewea  by  a user  process.  This  abstract 
macnine  will  be  implementeG  as  a combination  of  hardware  and 
software,  i.e.,  the  Multics  processor  enhanced  by  a set  of 
security  Kernel  procedures.  In  this  sense,  the  instruction  set 
of  the  aDstract  machine  is  seen  to  be  a combination  of  the  actual 
nardware  instructions  of  the  Multics  processor  plus  the 
"super-instructions"  represented  by  callable  entry  points  to  the 
kernel  procedures. 


The  specifications  alone  do  not  present  a complete  picture  of  the 
operation  of  an  abstract  machine.  As  mentioned  earlier,  they  are 
concerned  chiefly  with  the  aefinition  of  abstract  data  objects 
ana  operations  for  examining  and  manipulating  these  objects. 
Tney  ao  not,  however,  explain  how  these  operations  come  to  be 
executea.  The  answer  to  this  question  depends  upon  the  concept 
of  an  aostract  machine  interpreter  [BRl]  [Rob].  This  concept  is 
briefly  oescribed  below. 


13 


The  abstract  machine  interpreter  is  a very  general  processor  that 
has  an  associatec  instruction  set  as  mentioned  above.  The 
abstract  machine  interpreter  is  cognizant  of  a set  of  processes, 
eacn  of  which  is  known  to  be  either  ready  or  blocked.  For  each 
instruction  cycle,  the  abstract  machine  interpreter  first  selects 
a ready  process.  It  then  fetches  the  next  instruction  in  the 
instruction  stream  for  tnat  process.  This  instruction  is 
executed,  i.e.,  the  corresponding  0-,  V-,  or  OV-function  is 
invoked.  If  an  exception  occurs,  further  action  may  be  required 
by  the  abstract  machine  interpreter  depending  upon  the  particular 
instruction  ano  the  particular  error  involved. 

Although  this  characterization  of  the  abstract  machine 
interpreter  is  both  informal  and  incomplete,  it  hopefully 
provides  some  insight  into  the  mechanism  by  which  functions  come 
to  De  executed.  More  details  of  the  abstract  machine  interpreter 
will  be  revealed  in  the  specification  descriptions  that  follow. 


It  should  ce  noteo  that  functions  are  always  executed  in 
sequence,  i.e.  never  in  parallel.  Hence,  there  is  no  concern 
over  possible  interference  among  functions.  This  lack  of 
parallelism  would  be  impractical,  of  course,  in  a real 
implementation.  A technique  has  been  described  for  allowing 
controlled  parallel  execution  of  functions  without  the  danger  of 
harmful  interference  [BR2] . This  problem,  however,  is  beyond  the 
scope  of  this  report. 


CHAPTER  IV 


OVERVIEW  OF  THE  MULTICS  KERNEL  SPECIFICATION 


The  Multics  kernel  specification  is  divided  into  the  following 
modules : 

clock 

access_levels 

processes 

volumes 

quota  cells 

segments 

adoressspaces 

As  the  module  names  suggest,  each  module  takes  the  form  of  an 
object  manager,  i.e.,  each  module  defines  the  data  representation 
and  operations  for  a particular  object  type.  These  modules  are 
separately  aescribed  in  the  chapters  that  follow. 

Taken  together,  the  functions  of  the  modules  mentioned  above 
aefine  tne  top-level  kernel  interface.  As  described  earlier, 
nicden  V-functions  contained  witnin  these  modules  are  not  visible 
at  the  kernel  interface.  Similarly,  certain  0-  and  OV-functions 
are  also  hidden  from  the  kernel  interface.  This  hiding  is 
expressed  by  means  of  an  interface  specification.  An  interface 
specification  identifies  the  modules  that  compose  the  interface 
ano,  for  each  module,  identifies  functions  that  are  excluded  from 
tne  interface. 

Tne  Multics  kernel  interface  specification  is  shown  below. 
Unlike  the  module  specifications,  the  interface  specification  is 
not  written  in  SPECIAL.  A separate  interface  specif icatior 
language  (also  developed  at  Stanford  Research  Institute)  is  used. 
The  syntax  of  the  interface  specification  is  simply  a list  of 
module  names  enclosed  in  parentheses.  The  module  names  may 
optionally  be  followed  by  a "WITHOUT"  clause  that  names  functions 
whicn  are  explicitly  excluded  from  the  interface. 

In  the  chapters  that  follow,  reference  is  sometimes  made  to  0- 
and  OV-functions  that  are  hidden  from  the  kernel  interface.  All 
such  functions  are  named  in  the  "WITHOUT"  clauses  of  the  kernel 
interface  specification. 
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( 

INTERFACE  Multics_ker nel 
(clock) 

( access-levels) 


(processes 

( volumes ) 
(quota-cells 

( segments 

( aaor ess-spaces 
) 


WITHOUT  wake 

send_signal ) 


WITHOUT  set_quota 

change_qc_ref s 
change_qc_pages_used ) 

WITHOUT  reaa_seg 
wr i te_seg 
change_atu_dtm) 

WITHOUT  r evoke_vol_access 

purge_aoaress_scace) 
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CHAPTER  V 


THE  SYSTEM  CLOCK  AND  UNIQUE  IDENTIFIERS 


The  first  mooule  of  the  top-level  specification  describes  the 
system  clock.  A function  called  "read_clock"  is  defined  that 
returns  the  current  clock  value.  This  clock  value  can  be 
incremented  by  a second  function  called  "advance_clock"  that  is 
not  available  to  oroinary  processes.  It  is  convenient  to  think 
of  the  clock  mechanism  as  a special  autonomous  process  whose  only 
activity  is  to  increment  the  clock.  Mote,  however,  that  the 
clock  cannot  be  incrementea  during  the  execution  of  other 
functions.  The  fundamental  assumption  that  functions  do  not 
execute  in  parallel  applies  even  to  the  ticking  of  the  clock. 


Tne  clock  provides  a 
utilizea  by  various 
unique  identifiers  are, 
last  generated  uid.  A 
clock  advances  to  a ne 


source  of  unique 
components  of  tne 
indeed,  unique,  a 
request  for  a new 
w value. 


identifiers  that  are 
kernel.  To  ensure  that 
record  is  kept  of  the 
uid  must  wait  until  the 
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MODULE  clock 


DECLARATIONS 
INTEGER  time; 


FUNCTIONS 


VFUN  reaa_clock()  ->  time; 

5 (returns  current  clock  reading) 
INITIALLY  time  = 0; 

OF UN  aavance_clock ( ) ; 

$(aavances  clock  one  time  unit) 

EFFECTS 

' reaa_clock ( ) = read_clock()  + 1; 

OVFUN  get_uio()  ->  time; 

$ (generates  a new  uid) 

DELAY  UNTIL  reaa_clock()  > h_last_uia ()  ; 
EFFECTS 

time  = read_clocK ( ) ; 

' n_last_uid ( ) = time; 

VFUN  n_last_uia()  ->  time; 

$ (returns  last  uid  generatea) 

HIDDEN; 

INITIALLY  time  = 0; 


END  MODULE 
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CHAPTER  VI 


ACCESS  LEVELS 


The  access_leveis  moaule  is  the  only  module  of  the  kernel  that 
understanas  the  internal  structure  of  an  access  level.  As 
mentionea  earlier,  an  access  level  is  a combination  of  a security 
level  ana  an  integrity  level.  Each  of  these  two  levels  has  both 
a level  number  ana  a category  set.  Therefore,  an  access  level  is 
representea  by  a structure  witn  four  components. 

T'ne  access_levels  moaule  contains  functions  for  determining 
wnetner  or  not  a process  has  read,  write,  or  both  read  and  write 
access  to  a given  object.  These  functions  implement  the  security 
ana  integrity  access  control  policies  of  the  model.  The 
functions  take  as  input  a subject  access  level,  an  object  access 
level,  and  a coolean  value  inaicating  whether  the  subject  is 
trustea.  All  access  control  decisions  made  by  the  kernel  depend 
on  these  functions. 

In  current  Multics,  certain  processes  are  granted  privileged 
access  to  various  classes  of  objects.  In  the  kernel-based 
Multics,  privileges  associated  with  object  classes  will  not 
exist.  Insteau,  the  trusted  process  attribute  is  provided.  A 
trustea  process  having  the  maximum  security  and  integrity  levels 
will  have  both  read  and  write  access  to  objects  of  all  access 
levels . 
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NODULE  access  levels 


TYPES 

level_number  : {INTEGER  In  I U <=  In  AND  In  <=  max_ln}; 
category_set  : {VECTOR_GF  BOOLEAN  cs  | LENGTH (cs)  = cs_size}; 
access_level  : STRUCT  ( level_number  sin; 

category_set  scs; 
level_number  iln; 
category_set  ics)  ; 


DECLARATIONS 

access_level  sub_al,  ob_al ; 
INTEGEh.  i; 

BOOLEAN  b,  trustea; 


PARANETEKS 

level_numoer  max_ln  $ (maximum  level  number); 
INTEGER  cs_size  $ (category  set  size); 


FUNCTIONS 

VFUN  h_reaa_allowed (trustea ; sub_al;  ob_al)  ->  b; 

$(true  if  suoject  can  reaa  object) 

HIDDEN; 

DERIVATION  sub_al.sln  >=  oc_al.sln  AND 

(sub_al.iin  <=  ob_al.iln  OR  trusted)  AND 
(FORALL  i I i >=  1 AND  i <=  cs  size  ; 

(ob_al . scs ( i 1 =>  sub_al . scs [ i ] ) AND 
( ( sub_al . ics  [ i ] =>  ob_al . ics  [ i ] ) OR  trusted)); 

VFUN  h_wnte_allowec  (trustea;  sub_al;  ob_al)  ->  b; 

$(true  if  suoject  can  write  object) 

HIDDEN ; 

DERIVATION  (sub_al.sln  <=  ob_al.sln  OR  trusted)  AND 
sub_al.iln  >=  ob_al.iln  AND 
(FORALL  i i i >=  1 AND  i <=  cssize  ; 

( (sub_al . scs [ i]  =>  ob_al.scs[i]  ) OR  trusted)  AND 
(oo_al . ics  l i ] =>  sub_al . ics [ i ] ) ) ; 

VFUN  h_reaa_write_allowea (trustea;  sub_al ; ob_al)  ->  b; 

$(true  if  suoject  can  read  ana  write  object) 

HIDDEN; 

DERIVATION  h_reaa_al lowed ( trusted , sub_al,  ob_al)  AND 
n_wr ite_allowed (trusted,  sub_al,  ob_al); 

END  NODULE 
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CHAPTER  VII 


PROCESSES 


The  processes  module  is  concerned  with  the  creation  and  deletion 
of  processes,  interprocess  communication,  and  process  timers. 

At  process  creation,  the  access  level  of  the  new  process  and  the 
trusted  or  untrusteo  status  of  the  new  process  are  specified. 
Use  of  the  create_proc  function  is  restricted  to  the  initializer 
(trustea)  process  alone.  For  this  reason,  process  creation 
cannot  serve  as  an  information  path  between  untrusted  processes. 
Tnerefore,  knowledge  of  the  existence  of  processes  is  not 
restr ictea . 

Tne  processes  module  supports  the  familiar  block  and  wakeup 
primitives.  The  block  function  is  of  special  interest  to  the 
abstract  machine  interpreter  which  keeps  track  of  the  state  cf 
each  process,  i.e.,  blocked  or  ready.  In  addition  to  block,  a 
r ead_messages  function  is  provided  that  simply  reads  any  pending 
messages,  but  will  not  wait  for  a message  to  arrive. 

Tne  concept  of  event  channels  is  unknown  to  the  kernel.  The 
kernel  passes  messages  from  one  process  to  another  without 
concern  for  event  channel  identifiers  that  may  be  contained  ir. 
those  messages.  It  is  assumed  that  the  supervisor  will  implement 
event  channels. 

Tne  processes  module  also  supports  the  signal  mechanism. 
Functions  are  provided  to  seno  ana  receive  signals.  Ncte  that 
the  sending  function,  seno_signal,  is  hidden  from  the  kernel 
interface.  Thus,  a process  cannot  send  a signal  to  another 
process.  Signals  are  used  by  the  kernel  to  permit  immediate 
recognition  of  certain  kernel-aetected  events  such  as  quits  and 
alarms.  Tne  masking  of  signals  is  handled  outside  of  the  kernel. 

Tne  key  difference  between  signals  and  wakeups  is  that  a signal 
is  recognized  immediately  by  the  receiving  process  whereas  a 
wakeup  is  not  recognized  until  the  receiving  process  next  invokes 
the  block  or  r eaamessages  functions.  This  difference,  however, 
is  not  evident  from  the  specifications  alone  because  it  depends 
upon  the  operation  of  the  abstract  machine  interpreter.  It  is 
assumed  tnat  tne  abstract  machine  interpreter  is  designed  to 
cneck  the  signal  flags  for  a process  on  each  instruction  cycle. 
It  any  of  the  flags  is  set,  then  the  abstract  machine  interpreter 
causes  a fault  to  occur,  thereby  giving  the  process  an 
opportunity  to  use  tne  receivesignal  function.  At  the  time  a 
signal  is  sent,  the  abstract  machine  interpreter  checks  the  state 
of  the  receiving  process.  If  it  is  blocked,  then  a wakeup  is 
also  sent  to  the  receiving  process  (with  a dummy  message  that 
will  be  ignored) . The  purpose  of  the  wakeup  is  simply  to  force 
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trie  receiving  process  into  trie  ready  state  so  that  it  can  be 
iorcec.  to  tault  anc  notice  a pending  signal. 

Anotner  cuty  of  tne  processes  moaule  is  trie  support  of  real  time 
alarms.  hnen  setting  a real  time  alarm,  the  caller  must  specify 
tne  time  or  tne  alarm  anc  also  a wakeup  message.  If  this  message 
is  zero,  it  inaicates  that  tne  caller  wishes  to  receive  a signal 
at  tne  time  or  tne  alarm.  Ctnerwise,  a wakeup  is  desired.  The 
responsioility  of  watching  tne  clock  and  sending  tne  wakeup  or 
signal  rests  witn  the  aostract  machine  interpreter. 

Tne  present  i-iultics  supervisor  supports  the  concept  of  process 
virtual  time  (sometimes  called  "cpu  time").  In  essence,  process 
virtual  time  represents  the  real  time  that  a process  has  actually 
ueen  running  on  a processor  witn  suotractions  made  for  certain 
nicuen  events  suen  as  page  faults  anc  interrupts.  The  objective 
is  to  factor  out  time  spent  performing  hidden  operations  that 
support  tne  virtual  process  environment  because  this  time  is 
unpreoictaole  ano,  in  general,  depends  upon  tne  activities  of 
otner  processes.  Taken  to  tne  limit,  the  concept  of  process 
virtual  time  would  guarantee  a fixed  amount  of  time  for  the 
execution  or  eacn  supervisor  function.  However,  tne  current 
implementation  of  process  virtual  time  is  only  an  approximation 
eo  tnis  limit. 

unfortunately,  tne  current  metnoc  of  computing  process  virtual 
time  cannot  oe  specilieo  witnout  introducing  knowledge  of  events 
suen  as  page  faults  which  are  not  otherwise  visicle  in  tne 
to^-level  specification.  If  process  virtual  time  were  defined  in 
an  iceai  fashion,  i.e.,  if  a fixed  time  value  coulo  be  assigned 
to  eacn  lunction  in  the  top-level  specification,  then  a 
straigntforwaro  description  would  oe  cossicle.  Hailing  this, 
nowever,  no  acceptaole  metnou  of  specification  is  apparent, 
ineceiore,  tne  concept  of  process  virtual  time  Goes  net  appear  in 
tne  top-ievei  specification. 
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the  receiving  process  into  the  ready  state  so  that  it  can  be 
forced  to  rault  ana  notice  a pending  signal. 


another  outy  of  the  processes  module  is  the  support  of  real  time 
alarms.  When  setting  a real  time  alarm,  the  caller  must  specify 
the  time  of  tne  alarm  and  also  a wakeup  message.  If  this  message 
is  zero,  it  inaicates  that  the  caller  wishes  to  receive  a signal 
at  tne  time  of  the  alarm.  Otherwise,  a wakeup  is  desired.  The 
responsioility  of  watching  the  clock  and  sending  the  wakeup  or 
signal  rests  with  the  abstract  machine  interpreter. 

Tne  present  i-iultics  supervisor  supports  the  concept  of  process 
virtual  time  (sometimes  called  "cpu  time").  In  essence,  process 
virtual  time  represents  the  real  time  that  a process  has  actually 
oeen  running  on  a processor  with  subtractions  made  for  certain 
niuaen  events  such  as  page  faults  and  interrupts.  The  objective 
is  to  factor  out  time  spent  performing  hidden  operations  that 
support  the  virtual  process  environment  because  this  time  is 
unpreaictable  ana,  in  general,  depends  upon  the  activities  of 
other  processes.  Taken  to  the  limit,  the  concept  of  process 
virtual  time  would  guarantee  a fixed  amount  of  time  for  the 
execution  of  each  supervisor  function.  However,  the  current 
implementation  of  process  virtual  time  is  only  an  approximation 
to  this  limit. 

Unfortunately,  the  current  method  of  computing  process  virtual 
time  cannot  be  specified  without  introducing  knowledge  of  events 
such  as  page  faults  which  are  not  otherwise  visible  in  the 
top-level  specification.  If  process  virtual  time  were  defined  in 
an  ioeal  fasnion,  i.e.,  if  a fixed  time  value  coula  be  assignea 
to  eacn  function  in  the  top-level  specification,  then  a 
str aightforwaro  description  would  be  possible.  Failing  this, 
nowever,  no  acceptaole  method  of  specification  is  apparent. 
Therefore,  tne  concept  of  process  virtual  time  does  not  appear  in 
tne  top-levei  specification. 
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MODULE  processes 


TYPES 

level_numoer  : {INTEGER  In  I u <*  In  AND  In  <=  max_ln}; 
categoryset  : {VECTOR_OF  BOOLEAN  cs  I LENGTH (cs)  * cssize}; 
access_level  : STRUCT  (level_number  sin; 

category_set  scs; 
level_number  iln; 
categoryset  ics) ; 

process_uia  : INTEGER; 

message  : INTEGER; 

message_queue  : VECTOROF  message; 


DECLARATIONS 

process_uid  procuid,  newproc,  target; 
access_levei  al; 
message  msg ; 

message_queue  msg  queue; 

BOOLEAN  b; 

INTEGER  l,  n; 

INTEGER  time,  oelta  t; 


PARAMETERS 

processuia  initializet_ia  $( initializer  process  id); 

INTEGER  maxprocesses  $ (maximum  number  of  processes); 

INTEGER  max_messages  $ (maximum  size  of  process  message  queue), 
nsignals  $ (number  of  different  signals), 
real_timer_signal  $ (signal  code  for  real  timer  runout); 


DEFINITIONS 

INTEGER  first_signal (procuia)  IS 

MIN ( { i | h_signal_f lag (procuia , i ) } ) ; 

BOOLEAN  no_process (procuid)  IS 
'h_proc_exists (procuid) ; 

BOOLEAN  write_not_allowea (procuid ; al)  IS 

*h_wr ite_allowea (h_proc_trusted (procuid) , h_proc_al (procuid) , al) ; 


EATERNALREFS 
FROM  clock: 

VFUN  read_clock()  ->  time; 
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OVFUN  get_uid()  ->  procuid; 

FROM  access_levels: 

level_numoer  max_ln  § (maximum  level  number) 
INTEGER  cs_size  $ (category  set  size); 

VFUN  h_write_al lowed (b;  al;  al)  ->  b; 


FROM  adaressspaces: 

OFUN  purge_adoress_space (procuid) ; 


FUNCTIONS 

OVFUN  create_proc (al ; b) Iprocuid]  ->  newproc; 

$ (creates  a new  process) 

EXCEPTIONS 

procuid  ~=  initializer_id ; 
h_proc_count ( ) * maxprocesses; 
EFFECTS 

newproc  = EFFECTSOF  get_uid(); 

' n_proc_exists (newproc)  = TRUE; 

‘ n_proc_count ( ) = h_proc_count ( ) +1; 
' h_proc_al (newproc)  = al; 

‘ h_proc_tr ustea (newproc)  = b; 

VFUN  n_proc_exists ( procuid)  ->  b; 

$(true  if  process  exists) 

HIDDEN; 

INITIALLY  D = FALSE; 

VFUn  n_proc_count ( ) ->  n; 

S(numoer  of  processes) 

HIDDEN; 

INITIALLY  n = 0; 

VFuN  h_proc_al (procuid)  ->  al; 

5>  (returns  access  level  of  process) 
INITIALLY  al  = ? ; 

VFUN  proc_al ( ) (procuio]  ->  al ; 

$ (external  form  of  n_proc_al) 

DERIVATION  h_proc_al ( procuio ) ; 

VFUN  h_proc_tr usted (procuid)  ->  b; 

S(true  if  process  is  trusted) 

INITIALLY  b = ? ; 

VFUN  proc_trustea () [procuid]  ->  b; 

$ (external  form  of  h_proc_trusteo) 
DERIVATION  h_proc_tr ustea (procuid)  ; 

OFUN  aelete_proc (target) [procuio]; 

$ (deletes  a process) 
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EXCEPTIONS 

procuid  ~=  initializerid; 
no_process ( target) ; 

EFFECTS 

' n_proc_count ( ) = h_proc_count ( ) - 1; 

*h_proc  exists ( target)  = FALSE; 

EFFECTS_OF  purge_addr ess_space ( target)  ; 

OFUN  wake ( target ; msg) ; 

$ (transmits  a message  to  target  process 

if  target  queue  is  full,  message  is  lost) 

DEFINITIONS 

INTEGER  n IS  LENGTH (h_proc_rasg_queue (target) ) ; 

INTEGER  m IS  IF  n = max_messages  THEN  n ELSE  n+1; 
EFFECTS 

h_proc_msg_queue ( target)  = VECTOR  (FOR  i FROM  1 TO  m: 
IF  i <=  n THEN  h_proc_msg_queue ( tar get ) ( i J ELSE  msg); 

OFUN  wakeup (target;  msg) (procuid) ; 

$ (external  form  of  wake) 

EXCEPTIONS 

no_process ( target) ; 

wr ite_not_allowea (procuid,  h_proc_al (target) ) ; 

EFFECTS 

EFFECT3_0F  wake (target,  msg); 

OVFUN  reaa_messages ( ) (procuia)  ->  msg_queue; 

S (empties  message  queue  for  process) 

EFFECTS 

msg_queue  = h_proc_msg_queue (procuid) ; 

' n_proc_msg_queue (procuia)  * VECTOR  (); 

OVFUrt  olock () (procuia)  ->  msg_queue; 

$ (empties  message  queue  for  process 

if  queue  is  alreaoy  empty,  waits  for  message  to  arrive) 
DELAY  UNTIL  LENGTH ( npr oc_msg_queue (procuid) ) > U; 

EFFECTS 

LFFECTS_OF  r eaa_messages (procuid)  * msg_queue; 

VFON  h_proc_msg_queue (procuid)  ->  msg_queue; 

$ (returns  message  queue  for  process) 

HIDDEN; 

INITIALLY  msg_queue  = VECTOR  (); 

OFUN  send_signal (target;  n) ; 

5 (sends  signal  n to  target  process) 

EFFECTS 

' h_signal_f lag (target,  n)  ® TRUE; 

OVFUN  receive_signal () (procuid)  ->  n; 

$ (receives  lowest  nuoiDer  signal) 

EFFECTS 

n = first_signal (procuia) ; 
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n > 0 *>  ' h_signal_f lag (procuid , n)  * FALSE; 

VFUN  h_signal_f lag (procuid;  n)  ->  b; 

$(true  it  signal  n sent  to  process) 

HIDDEN ; 

INITIALLY  b = FALSE; 

OFUN  set_real_timer (deltat;  msg) (procuid) ; 

$(sets  real  timer  alarm  for  process) 

EFFECTS 

'h_real_timer (procuid)  = (IF  delta_t  <*  0 THEN  ? 

ELSE  read_clock()  + delta_t) 
oelta_t  > 0 *>  ' h_real_timer_msg (procuid)  = msg; 

VFUN  n_real_tiraer (procuid)  ->  time; 

$ (returns  time  of  next  real  timer  alarm) 

HIDDEN; 

INITIALLY  time  = ?; 

VFUN  h_real_timer_msg (procuid)  ->  msg; 

$ (returns  real  timer  wakeup  message) 

HIDDEN; 

INITIALLY  msg  * ?; 


END  NODULE 


CHAPTER  VIII 


VOLUMES 

A volume  is  a logical  suDdivision  of  secondary  storage.  A 
single  volume,  may  comprise  one  or  more  physical  storage 
devices,  i.e.,  disk  packs,  although  this  fact  is  largely 
concealed  outsiae  the  kernel.  The  volumes  module  is  concerned 
only  with  volume  creation  and  deletion  and  volume  mounting. 
The  control  of  volume  storage  space  is  handled  by  other 
moaules. 

At  the  time  a volume  is  created  (i.e.,  registered),  minimum 
and  maximum  access  levels  for  the  volume  are  specified.  These 
access  levels  delimit  the  range  of  access  levels  of 
information  that  can  be  storea  on  tne  volume.  The  minimum 
access  level  of  the  volume  also  serves  as  a visibility  access 
level  for  the  volume.  The  protection  of  information  stored  on 
a volume,  however,  does  not  depend  on  these  access  levels. 
Each  object  that  resides  on  a volume  must  have  its  own  access 
level.  Tne  purpose  of  the  volume  access  levels  is,  for  the 
most  part,  to  satisfy  certain  operational  requirements.  For 
example,  highly  sensitive  information  can  be  segregated  onto 
specific  disk  packs  that  receive  special  handling. 

Also,  at  volume  creation  time,  an  initial  quota  cell  is 
created  for  a volume.  The  quota  value  of  the  quota  cell  is 
set  to  the  volume  size,  i.e.  the  number  of  pages  on  the 
volume.  The  role  of  the  initial  quota  cell  is  explained  in 
the  description  of  tne  quota_cells  mooule. 

The  specifications  place  no  limit  on  the  number  of  volumes 
tnat  can  be  created.  In  practice,  however,  the  kernel  would 
neea  to  maintain  a table  of  volumes.  If  any  process.  an 
create  a volume,  tne  taole  becomes  an  instance  of  the  shared 
finite  resource  problem.  A simple  solution  woula  be  to 
restrict  tne  creation  of  volumes  to  trusted  processes. 

The  only  operations  that  can  be  performed  on  a volume  are 
mounting  and  demounting.  ,Both  of  these  operations  require 
that  the  user’s  access  level  be  equal  to  the  volume  minimum 
access  level.  This  is  necessary  because  the  mounting  and 
demounting  of  a volume  can  be  detected  by  any  process  at  an 
access  level  equal  to  or  greater  than  the  volume  minimum 
access  level. 

Unfortunately,  volume  mounting  produces  another  instance  of 
the  snarea  finite  resource  problem.  In  this  case,  the  finite 
resource  is  the  collection  of  disk  drives.  The  mounting  and 
demounting  of  volumes  could  be  restricted  to  trusted 
processes.  Tnis,  however,  seems  clumsy  and  undesirable. 
Another  possibility  is  to  assign  access  levels  to  the  disk 
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drives.  Tne  kernel  could  then  require  that  for  a process  to 
mount  a volume  on  a disk  drive  (or  set  of  drives)  the  process 
access  level,  the  volume  minimum  access  level,  and  the  drive 
access  level  must  all  be  equal.  Tne  access  levels  of  disk 
drives  coulo  be  changed  dynamically,  if  necessary,  by  a 
trusted  process  presumably  under  operator  control. 

After  mounting  a volume,  a user  might  find  it  necessary  to 
destroy  his  current  process  and  create  a new  process  at  a 
greater  access  level  in  order  to  use  information  on  the  volume 
having  an  access  level  greater  than  the  volume  minimum. 
Later,  the  user  must  again  create  a new  process  at  the  volume 
minimum  access  level  in  order  to  issue  a demount  request. 
This  inconvenience  is.  of  course,  aue  to  the  fact  that  volumes 
are  multiple  access  level  objects.  If  volumes  were  restricted 
to  a single  access  level,  this  problem  would  vanish.  However, 
a requirement  to  dedicate  a whole  volume  (at  least  one  full 
axsk  pack)  to  a single  access  level  might  be  economically 
unoesiraole.  In  any  event,  single  access  level  volumes  are 
simply  a degenerate  case  of  multiple  access  level  volumes. 
Tnerefore,  it  is  always  possible  to  create  single  access  level 
volumes  if  uesireu. 

Tne  aoove  discussion  of  volume  mounting  is  concerned  with  the 
actual  physical  mounting  of  volumes.  The  current  Multics  user 
interrace,  nowever,  supports  the  concept  of  volume  attachment. 
A process  must  attach  a volume  before  using  it.  The  first 
process  to  attach  a volume  causes  it  to  be  mounted. 
Similarly,  the  last  process  to  oetach  a volume  causes  it  to  be 
demounted.  Tnis  scneme  cannot  be  entirely  supported  because 
of  tne  previously  explained  need  for  a user  to  change  access 
levels  (and  nence  processes)  during  the  time  that  a volume  is 
mounted . 
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MODULE  volumes 


TYPES 

level_numoer  : {INTEGER  In  | 0 <=  In  AND  In  <=  max_ln}; 
category_set  : {VECTOR_GF  BOOLEAN  cs  I LENGTH (cs)  = cs_size}; 
access_level  : STRUCT  ( level_number  sin; 

categoryset  scs; 
level_numoer  iln; 
category_set  ics) ; 

process_uia  ; INTEGER; 
volume_uia  ; INTEGER; 
quota_cell_uia  : INTEGER; 


DECLARATIONS 

volumeuid  voluia; 
process_uia  procuia; 
quota_cell_uia  qcuia; 
access_level  minal,  max_al,  al; 
BOOLEAN  o; 

INTEGER  i ; 


PARAMETERS 

INTEGER  volume_size  $(numoer  of  pages  on  a volume); 

DEFINITIONS 

BOuLEAN  unoraerea_access_levels (min_al;  max_al)  IS 
~h_wr 1 te_al lowea (FALSE , min_al,  max_al) ; 

BOOLEAN  wr i te_not_allowed (procuid ; al)  IS 

'n_wr l te_al lowea (n_proc_ trusted (procuia) , h_proc_al (procuid) , al ) 

BOOLEAN  no_volume (procuid ; voluid)  IS 

IP  "h_vol_exists (voluid)  THEN  TRUE 

ELSE  ~h_reaa_al lowea (n_proc_tr us tea (procuid) , h_proc_al (procuid) , 

h_vol_min_al (voluid) ) ; 

BOOLEAN  mounted_volume (voluid)  IS 
n_vol_mountea (voluia)  ; 

BOOLEAN  unmounted_volurae (procuid;  voluia)  IS 
IF  ~n_vol_mountea (voluid)  THEN  TRUE 

ELSE  ~h_read_allowea (h_proc_tr ustea (procuid) , hjprocal (procuid) , 

ti_vol_min_al  (voluid)  ) ; 
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clocX : 

OVFUu  get  uic()  ->  voluic; 
access  levels: 

levelnumcer  max  In  $ (maximum  level  number); 

IHTEGth  cs  size  $ (category  set  size); 

VFU«  n write  alloweo(b;  al ; al)  ->  b; 
vFUX  n reao_aliowec (b;  al;  si)  ->  b; 

processes : 

vrUJ  n proc  al  (procuio)  ->  al ; 

VFUW  n proc  trustee (procuid)  ->  o; 

quotaceils : 

create  quota_cell (voluic ; al;  al)[prccuid]  ->  ccuic; 
CFuw  se t_quota (ccuic ; i); 

aaoress  spaces: 

OF Ua  revoke  vox  access ( vo luid ; procuio); 


r Lu^CTIOkS 

i createvolume (min  al;  max  al) [procuio]  ->  voluic; 

? (creates  a new  volume) 

OC.F  III  I T IoiMO 

quota  cell  uio. ccuic  IS  ‘h  vol  init  qc(voluid); 
uaGcFTIOLS 

unorcereu  access  levels (min  al,  max  al); 
writenot  alloweo (procuio , min  al); 

LFF  t.CTS 

voluic  = EFFECTS  _GF  get  uid(); 

* n vcl_exists (voxuio)  = TREE; 

’n_vol_min  al  (voluic)  = min  al; 

•n  vol_max  al (voluic)  = max  al; 

qcuic  = EFFECTS_OF  create_quota  cell  (voluic,  min_al,  min_al , 

procuio) ; 

LF  FtCT5_GF  set_quota (qcuic  , volume  size); 

n volexists  ( voluici)  ->  o; 

V(true  it  volume  exists) 
rii  LixlN  ; 

Ilm  11 IALEY  0 = FALSE  ; 

n_vol_min_al (voluic)  ->  min  ai; 

S (returns  minimum  access  level  of  volume) 

HlLLLi'i ; 

INITIALLY  min  al  = ?; 

vcl_min  al  (voluic) [procuio]  ->  min  al; 
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$ (external  form  ol  n_vcl_min_al) 

EaCLPTIOUS 

no  volume ( procuio , voluid); 
utKI VATICA  n vol  minal (voiuio) ; 

v r Uoi  n_vcl_max  al (voluid)  ->  max  al; 

^ (returns  maximum  access  level  of  volume) 

H1L0LM ; 

I a IT I ALLY  naxal  = ?; 

VcUit  vol  max  al (voiuio)  l procuio]  ->  maxal; 

^ (external  form  of  n vol_max_al) 

L.ALUpTIGt'iS 

no  volume (procuio , voluid)  ; 

DERIVATION  n vol  max_al (voluid) ; 

VrLD  n_vol  init  cc  (voluic)  ->  qcuia; 

» (returns  initial  quota  cell  uic  tor  volume) 
iilLDLu ; 

INITIALLY  ccuio  = ?; 

vtbu  vol_init_qc (voiuio) Iprccuia]  ->  ccuio; 

(external  form  of  n vol  init_ac) 

L Adijli1  Idi.d 

no_volume (procuio , voluid); 
uuRlvATION  n vcl_ir.it  ac  (voluic); 

or  u;.  cole te_vol ume  (voiuio)  (procuio  j ; 

Mueletes  a volume) 

Lao l PI  Io.«d 

no_volume ( procuio , voluic); 
mounteo  volume (voiuio)  ; 

write  not_allowec (procuio  , h_vol_m in _al (voiuio) ) 

Lee L C I D 

’ n_vol_exists (voluid)  = FALSE ; 

Or  La  mount_volume (voiuio) (procuio] ; 

$ (mounts  a volume) 

L.  Aw  LPTIOaO  ^ 

no_volume (procuio , voluic); 
mounteevolume (voluid)  ; 

wr ite_not_al loweo ( procuio , h vol  min  al  (voiuio)) 
EFFECTS 

1 n_vol  _ir,ounted  (voiuio)  = TRUE; 

v run  n _vol_m.cunteo  (voiuio)  ->  d; 

•?(true  it  volume  is  mounteo) 

lilbOC 

IiiITlnLLl  c = FALSE; 

or  La  oemount_volume ( voiuio)  (procuid]  ; 

$ (demounts  a volume) 

EXCEPTIONS 


31 


ur..nounteu  volume  (pcocuio  , voluid)  ; 
write  no tallcweu  (procuid , h vol  min  ji  (voluid)  ) ; 
EFFECTS 

‘ n_vol  mounted  (voluid)  = FALSE ; 

fc.FFtCT.j_GF  revoke_vol_access  ( voluia  , procuid); 


tk'.U  iiGwGLt. 


CHAPTER  IX 


CELLS 


vuota  cells  are  the  mechanism  by  which  the  snaring  of  pages  on 
a volume  is  controllec.  Each  segment,  and  hence  each  page  of 
eacn  segment,  is  assignee  tc  a particular  quota  cell.  having 
no  Knowieuge  of  oireccories,  tne  kernel  presents  a general 
interface  that  woulo  allow  any  arbitrary  collection  of 
segments  having  the  same  access  level  to  be  assigned  to  the 
same  quota  cell.  The  supervisor,  nov/ever,  will  impose  an 
arrangement  or  quota  ceils  ano  segments  tnat  reflects  the 
oircctory  merareny.  Thus,  the  corr.tinec  operation  of  the 
supervisor  ana  kernel  wiii  prccuce  a quota  mechanism 
essentially  equivalent  tc  tnat  of  current  Multics. 


At  tne  time  a quota  cell  is  createc,  a volume,  an 
level,  ana  a visioility  access  level  are  specifieo. 
access  levels  must  ce  within  tne  volume  range, 
interest  or  n, axing  volumes  self-cescr  ibino  (anc 
invulnerable  to  the  failures  of  ctner  volumes)  , it  is 
tnat  all  quota  cells  rcr  a volume  are  stereo  on  th 


access 
The  two 
In  the 
tnerebv 
assurr.ee 
e volume 


itself. 


otorage  space  on  a volume  is  first  mace  available  bv  the 
creation  of  an  initial  quota  celi  as  previously  uescricec. 
octn  the  access  level  anc  tne  visibility  access  level  oi  an 
initial  quota  cell  must  equal  tne  volume  minimum  access  level. 
As  uescrioec  celow,  this  permits  tne  initial  queta  to  be 
uistricutec.  to  nigher  access  levels  as  necceo. 

Aside  from  tne  initial  quota  cell,  ail  ctner  quota  ceils  are 
createu  with  a quota  of  2ero  pages.  In  order  to  assign  a 
non-zero  quota  to  a new  quota  celi,  quota  must  be  rnovecr  frem. 
some  ctner  quota  celi  cr.  the  same  volume.  Lith  regard  to 
access  ievels,  quota  cannot  be  noveo  cownwaro,  i.e.,  the 
move_qucta  operation  insists  tnat  tne  target  quota  ceil  have 
an  equal  or  greater  access  level  than  the  source  quota  cell, 
only  trustee  processes  can  move  quota  downward. 

A reference  count  is  associatec  with  each  queta  cell.  This 
count  is  tne  numoer  of  segments  tnat  charge  pages  to  tne  quota 
ceil.  So  long  as  this  count  is  non-zero,  tne  cuota  cell 
cannot  oe  celeteo. 

Anc tne r attricute  ci  a quota  cell  is  tne  count  of  pages  used, 
inis  count  is  cnangea  cy  tne  creation  ana  eolation  of  pages  in 
associateu  segments  as  specif ieu  in  tne  segments  moculo.  Tor 
all  quota  cells,  the  pages  usee  count  is  not  permitted  to 
excetu  tne  quota. 
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Tne  quota  cells  module  is  also  responsible  for  metering  tne 
use  or  pages  for  accounting  purposes.  To  tnis  end,  the  pages 
usca  count  is  integrator;  over  time  to  prooucc  a "time-record 
proauct"  (trp).  Each  time  the  pages  used  count  is  changed, 
cne  tr?  must  ce  upuateu.  If  a quota  cell  is  deleted,  its  trp 
must  be  aoueu  to  tnat  of  some  other  quota  cell  on  tne  same 
volume  so  tnat  prior  usage  of  tne  cieleted  quota  cell  will  be 
accountec  tor.  A function  is  also  provided  to  read  ar.o  reset 
to  zero  tne  trp  of  a quota  cell.  This  function  is  needed  by 
tne  accounting  systemi  to  collect  charges  for  one  billing  cycle 
uHCi  f ci  £ CilC  Sctilk  e time,  begin  a new  cycle. 

As  described  above,  tne  quota  cell  mechanism,  controls  the 
sharing  of  pages  among  uiiferent  access  levels  and  thus 
represents  a solution  to  tne  shareo  finite  resource  problem 
for  pages.  This  solution  oepenos,  however,  on  tne  assumption 
tnat  quota  cannot  Le  over-ai iocateo  as  is  current  practice  at 
some  Multics  sites.  li  this  were  permitted,  i.e.,  if  the 
quota  for  a volume  cculo  be  set  nigner  than  the  actual  number 
of  available  pages,  tnen  the  exhaustion  of  pages  on  a volume 
coulc  occur  before  the  exhaustion  of  quota.  This  would 
constitute  an  uncontrolled  information  path.  Of  course,  on 
single  access  level  volumes,  this  information  path  is  of  no 
consequence.  hence,  it  would  be  possiole  to  allow 
over-allocation  ci  quota  on  such  volumes. 

iso  limit  is  piacco  on  the  r.umoer  of  quota  cells  that  can  be 
creates  on  a volume.  Ironically,  in  attempting  to  solve  one 
instance  of  tne  snared  finite  resource  proclem,  a new  instance 
is  creates.  ■ Some  methco  for  controlling  the  number  of  quota 
ceils  on  a volume  is  neeoed. 

iue  proposed  quota  cell  mechanism  yields  two  incompatibilities 
witn  tne  current  Aultics  quoca  scheme.  First,  it  will  not  be 
possiole  to  convert  a directory  from  terminal  quota  status  to 
non-terminal  quota  status  or  vice  versa.  Seccr.o,  a "pages 
usco"  value  will  not  be  maintained  for  non-terminal  quota 


both  of  tne  aoeve  incompatibilities  stem  from  a single 
simplification  of  one  quota  ceil  mechanism.  In  current 
iiuitics,  there  exists  a class  of  "indirect"  quota  cells, 
specifically,  these  are  the  quota  cells  associated  with 
non-tcrmir.ai  quota  directories.  In  order  to  aeterminc  whetner 
a page  can  be  aooeG  to  a segm.ent  in  such  a directory,  it  is 
necessary  to  follow  a chain  of  indirect  quota  cells  until 
reacr.ing  a quota  cell  associated  with  a terminal  cuota 
oirectcry.  In  the  proposed  kernel  quota  mechanism,  there  are 
no  indirect  quota  cells.  Tnis  eliminates  a significant  amount 
of  complexity  ana,  at  tne  same  time,  produces  the  two 
aforementioned  incompatibil ities . 
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Tne  impact  of  tnese  incompatibilities  on  users  can  be 
estimateo.  Tne  restriction  on  converting  directories  between 
terminal  ano  non-terminal  quota  status  should  have  little  or 
no  etiect  on  the  vast  majority  of  users.  rit  single  access 
level  sites,  quota  will  rarely  be  moved  below  the  user  home 
airectcry  levei.  Statistics  gathered  on  the  MIT  system 
support  tnis  claim  IJanJ  . At  multiple  access  ievel  sites, 
quota  will  oe  ir.oveo  below  tne  user  home  directory  level  to 
accomodate  upgraded  cirectories.  In  current  Multics,  upgraded 
directories  are  required  to  nave  a quota  at  all  times  anc  thus 
already  ooey  tne  proposed  restriction.  The  elimination  of  a 
pages  usco  value  lor  non-terminal  quota  directories  may  have  a 
more  serious  impact.  At  certain  times,  tnis  feature  could  be 
valuaoie  to  any  user.  Of  course,  it  is  always  possible  to 
calculate  tne  pages  useu  of  a subtree  (with  some  dynamic 
uncertainty)  oy  summing  tne  pages  used  of  every  segment  in  tne 
subtree.  Tnis  could  oe  an  expensive  operation.  however , if 
done  mirequently , tne  cost  may  still  be  less  than  tne 
constant  overneau  associated  with  maintaining  indirect  cuota 
celis.  remember  tnat  indirect  quota  cells  waste  wired  memory 
ano  require  extra  computation  at  page  fault  time.  lerhaps 
some  insignt  could  oe  gained  by  metering  the  frequency  of 
requests  tor  tne  pages  usea  value  of  indirect  quota  cells  in 
current  i-iultics. 

Two  ctner  aspects  of  tne  way  tne  supervisor  is  expected  to  use 
quota  cells  deserve  mention.  first,  tne  pages  of  a terminal 
quota  directory  will  oe  cnargeo  to  tne  cuota  cell  associated 
witn  tnat  directory,  not  to  tne  quota  cell  of  a parent 
directory.  Tnis  is  necessary  to  meet  security  requirements 
tor  an  upgraded  directory.  Second,  tne  supervisor  may  permit 
quotas  to  oe  assigned  to  individual  non-directory  segments. 
Tnis  would  allow  tne  creation  oi  upgraded  segments,  a feature 
not  rouno  in  current  Mutlics. 


wGDULE  quota  cells 


TYPES 

ievel_numcer  : {INTEGER  In  l 0 <=  In  AND  In  <=  max  _ln}; 
category  set  : {VECTOkCF  BOOLEAN  cs  | LENGTH (cs)  = cs  size}; 
access_ievel  : STRUCT  { level_numcer  sin; 

categoryset  scs; 
level  nuititer  iln; 
category  set  ics) ; 

process_uia  : INTEGER; 

VOlumeuia  : INTEGER; 
quota  cell  uia  : IN  i EGt,K ; 


gc  C LArAT  IONS 

process_uia  procuia; 
volume_uia  voluia; 

quota_cell_uia  qcuio,  from_qcuio,  to_ccuid; 
access_ie v(.l  al,  val; 

InlLoc.h  npages,  n; 

INTgGEr  time,  trp; 
joULlAh  u; 


LEFIN ITTOmS 

ovOLlAh  unrr.ountea_volu.~e  ( procuia ; voluia)  IS 
IF  ~n_vol_mountea (voluia)  THEN  TRUE 

ELSE  ~n  reaa_al lowea  (n  prcc _tr ustea (procuia)  , h proc_ai ( procuia ) , 

n_voi_min  al (voluia) ) ; 

cooLlh..  outsiae  voi_levels  (voluia;  val;  al)  IS 

'n  wr i tealloweo ( FALue , nvol  ir.in_ai  ( voluic)  , val)  OK 
"n_wr 1 te  al lowea (FALSE , al,  hvol  max  al(voluid)); 

LoulLrii.  uncrcerea  access_level s ( val ; al)  IS 
"n_write  aliowea (FALSc,  val,  al); 

aoCLaA..*  write  not  aliowea (procuia ; al)  IS 

'nwrite  aliowea  (n  proc  trustee (procuia) , h prcc  al (procuia) , al) 

oEoLlA.j  no  quota  cell  (procuia;  voluia;  qcuia)  IS 
IF  ~h  qc  ex ists (voluia , qcuia)  THEN  TRUE 

ELSE  ~n  reaa  allowea(n  proc  trusted (procuia) , h proc  al (procuia), 

n qc  visioility  al  (qcuia)); 

saaLE  iu-*  reaa  not  aliowea (procuia ; al)  IS 

*n  reaa  allcweu(n  prcc  tr us  tec ( procuia ) , h prcc  al(crocuid),  al); 

juuLlAh  reaa  write  not  allowed  (procuia ; al)  IS 
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~d  reaci  write  ailoweo  (n  proc  trusted  (procuici)  , h prcc  al (procuio) 

al)  ; 

uuGLlAi,  non  zero  quote  (qcuio)  IS 
n qc  pages (qcuio)  ~=  u; 

oGCLEAd  non  zero  refs (qcuio)  IS 
nac  rets(qcuiu)  ~=  o; 

tbJCLLAd  invalic  quota_cnange  (npages ) IS 
npages  < u ; 

no'GLLAd  insuf 1 ic ient  quota (qcuio ; npages)  IS 

n_qc  pages (qcuio)  - h qc  pages  useo(ccuio)  < npages; 


EAlc.ru'tALALf  S 
cIoca : 

VFUd  reao  clock  ()  ->  time; 

GVFUi.1  get  uic()  ->  qcuio; 

t uCi-i  access  levels: 

level  number  max  In  $ (maximum  ievei  number); 
l.«TEGEK  cs  size  .?  (category  set  size); 

VFUu  n reao  aliowec(b;  ai ; al)  ->  c; 

Vr  Ur.  n write  ailoweo (b;  al;  ai ) ->  b; 

VtU  n reao  write  ailoweo  (b;  al ; al ) ->  o; 

FnOi'i  processes: 

v r n proc  al(prccuio)  ->  ai; 

Vrui'i  n proc  tr  usteo  (procuio)  ->  b; 

caC.i  volumes: 

vt'UiM  n_vol  mounteu  ( voiuio)  ->  b; 

Vt'uci  n vcl  min  ai  (voiuio)  ->  al; 

VcUW  n voi  max  al (voiuio)  ->  al ; 


t UdC'I'IGUS 

OVr’lb«  create  quota  cell  (voiuio;  val  ; al)[procuid]  ->  qcuio; 
^(creates  a new  quota  cell) 

LaCEFTICNs 

unoroered  access  levels(val,  al); 
writenot  ailoweo (procuio , val); 
unmounteo  volume  ( procuio  , voiuio); 
outsiue  voi  levels (voiuio , val,  al); 

Lie LCTs 

qcuio  = EFFECTS  OF  get  uio(); 

* b qc  al (qcuio ) = al ; 

‘h  qc  visibility  al(ccuio)  = val; 
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*h  qc  exists (voluic , ccuid)  = TKUE ; 

VFU.m  n uc  exists  (voluid;  qcuic)  ->  b; 

$(true  if  quota  cell  exists) 

HIDbEN ; 

INITIALLY  b = FALSE; 

VFtiN  n qcvisibil i ty_al (qcuia)  ->  al ; 

S (returns  access  level  of  quota  cell  visibility) 
rilLDEN ; 

INITIALLY  ai  = ? ; 

vt'uu  qc_visibil  ity_al  (vcluio  ; qcuia )[  crocuid ] ->  al ; 

^(external  lorm  of  h_cc_visibility_al) 
bACLPTlONS 

unr.iOuntec_volu;r.e  ( procuic  , voluid)  ; 
no_quota_celi (procuxo , voluia,  qcuic) ; 
bt-Al VAilOi'i  n ac_visibility  £l  (qcuic)  ; 

vcl.<  n_qc  al (qcuia ) ->  al ; 

> (returns  access  level  of  quota  cell) 

H 1 Lb  bi'i  ; 

INITIALLY  Cl  = ?; 

vru.i  qc_al (voluic ; qcuic) 1 procuio j ->  al ; 
y (external  form  of  n_cc_al) 
b ACLPT  I di'JS 

unrr.ountec_volurr.e  ( prccuid , voluid)  ; 
no_cuota_ceil (prccuia , voluid,  ccuia); 
bbi\I  VaTIOl;  n qc  al  (qcuia); 

CFbN  se t_cuota (qcuic ; npages); 
d(sets  quota  or  quota  cell 

ugeu  only  to  initialize  first  quota  cell  on  a volume) 
bfFECTS 

‘n_qc  cages (ccuia)  = npages; 

oFUw  r.\ove_quota  (voluic  ; f r err.  _qcuia  ; to_qcuic;  npages )[  prccuid  J ; 

S (moves  page  quota  from  one  cell  to  another) 

EXCEPTIONS 

invalic  quota_change (npages)  ; 
unmour.tea_vol  ume  ( prccuid  , voluid) ; 
no_quota_celi (procuic , voluic,  from_qcuic) ; 
nc  quota _cell (procuio , voluic,  to_qcuic) ; 
reac  _write_r.ct  allowec  (prccuid  , h_qc  al  (f  rcm_qcuid)  ) ; 
write  not_ailowec (procuid,  n_qc  al ( toqcuic ) ) ; 
insuf f icicnt_quota ( f r om_qcuic , npages) ; 
br  FbCTS 

‘ n_qc  pages ( 1 romccuic ) = h_qc  pages  (from,  qcuic)  - npage 
'h_qc  payes(to_qcuio)  = h_qc  pages ( to_qcuic ) + npages; 

vr'UN  n_qc_pages  (qcuic)  ->  npages; 

(returns  page  quota  for  cuota  cell) 


hlODLtJ ; 

INITIALLY  npages 


= U; 

Vr'u  m qc_pages (voluia ; qcuiu ) l procuia  ] ->  npages; 

;?  (external  terra  cf  h_qc_pages) 

EXdc.F'1  IvJuS 

unmountea_volume ( procuia , voluia)  ; 
nc_qucta_cell (procuia , veluia,  ccuia); 
reaa  _not_sllowea (procuid,  h _qc_ai {ccuid) ) ; 

EcEI  vA'i  ION  n_qc  pages  (ccuia ) ; 

Vc’uiM  n_cc  refs (qcuid)  ->  n; 

$ (returns  quota  cell  reterence  count) 
iiibDtN ; 

INITIALLY  n = L; 

vrou  qc_rets (voluiu ; qcuiu ) i procuid  J ->  r. ; 

;?  (external  form  cf  hacrefs) 
t aCuTTIGNS 

unmounteu  volume (procuia , voluic) ; 
no_quota_ceil (procuia , veluia,  qcuia) ; 
reaa_not_allowea (procuia , n_cc  _al (ccuia) ) ; 
uLRI VAxICN  n acrefs (qcuiu ) ; 

vt  Lw  ciiange_qc  rets(qcuic;  n)  ; 

$ (cnanges  quota  ceil  rererer.ee  count) 

Lr  r uCTS 

‘ n_qc_ref s (qcuid)  = n qc_rets (qcuid ) + n; 

or  ua  aeiete_quota_cell ( voiuia ; qcuia;  to  qcuia )[ procuia ] ; 

^(ae-ietes  a quota  ceil) 
t AOuPTIo^o 

unmountea_volume (procuia , voluiu)  ; 

no_quota  cell (procuia , voluiu,  ccuia); 

no_quota_cell (procuia , voluia,  tc_qcuia) ; 

wnte_nct_allowea  (procuia , n _qc_visicility  al (qcuia)); 

reaa  not _ailo wee (procuia,  hqcal (ccuia) ) ; 

wr 1 te_not_allcwea (procuid,  n _cc_ai ( tc_ccuia ) ) ; 

non _zerc_cuot£ (ccuia ) ; 

nonzero  rers(qcuia); 

EttcCIS 

’ h_qc _trp ( to _ccuia ) = h_cc_ tr p ( tc_qcuic ) + h_qc_trp (ccuid ) ; 
1 n_qc_exists ( voluia , ocuidl  = FALSE; 

vrd.4  n qc_pages_usea (qcuid ) ->  npages; 

> (returns  pages  useu  tor  cucta  cell) 
u I LDu.4 ; 

INITIALLY  npages  = u; 

vcua  qc _pages_usea  (voluia ; qcuia )[ procuid)  ->  npages; 
v (external  torm  cf  d_qc_pagcs_u30d) 
laC EFT IONS 

unmount ea_volume (procuia , voluia) ; 
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no_quota_cell (procuia , voluid,  acuic) ; 
reao_not_allowea (pcocuid , h_qc  al (qcuid)); 

LmlVAlION  n_qc_pages_usec (qcuio) ; 

Ot'UiM  cnange_cc_pages_usec (ccuio ; npages)  ; 

$ (changes  pages  used  lor  quota  cell) 

UEf  In  1 1 IuNS 

INTEGEK  time  IS  1 h_qc_tr p_upaa tec (qcuid ) 

- h_qc_trp  updated (qcuid) ; 

EFFECTS 

‘ h_qc_pages_useu (qcuia)  = n qc_pages  used (ccuid)  + npaaes; 
,h_qc_trp_updatea (qcuid)  = rcaa  clock(); 

‘ n_ac_trp (qcuic)  = n_qc_trp (ccuio)  + 

(time  * hac_pages_used (ccuid) ) ; 

vrou  nqc_ trp (qcuid ) ->  trp; 

s (returns  tirae  record  product  of  cuota  cell) 
ill  u u c.N ; 

INITIALLY  trp  = o; 

vcun  n_qc_tcp_upuatcd (qcuia ) ->  time; 

S (returns  time  trp  last  upcated) 

ti  1 bbLkt  / 

INITIALLY  time  = 0; 

vrU«  qc_trp (voluio ; qcuio ) [ procuid ] ->  trp; 

9 (external  terra  of  h_qc_trp) 

OoFIn  I nows 

INTEdEts  tirae  'IS  read_cloc*()  - h qc  tr p_updatec  (acuid)  ; 
c.XOEFTICi'.S 

unmounteo_volume (procuio , voluid) ; 
nc_cucta_celi (prccuia , voluio,  qcuid); 
reau_not_aliowed (procuid , h_qc  al (qcuid)); 

EEEIVATIOW  n_qc_ tr p ( qc ui d ) + (time  * h qc_pages  used (ccuic) ) ; 

OVtUW  resettrp (voluid;  qcuio) ( procuio ] ->  trp; 

S (reaos  ana  resets  trp  tor  new  accounting  cerioc) 

LoFINITICWS 

IWTEGEk  time  IS  reao_clock()  - h_qc_tr p_updatec (ccuid) ; 
except lows 

unm.ounteo  volume  (procuid,  voluid)  ; 

no_quota_cell (procuid , voluid,  ccuio); 

reao  wri te_not_allowed (procuid , n_cc  al (ccuid)); 

LFFECTS  ~ 

trp  = h_qc_trp (qcuio)  + (time  * h qc_paaes_used (qcuio) ) ; 
’h_ac  trp(qcuio)  = 0; 

'h_qc_trp_updatea (qcuio)  = reao  clock (); 


L+1U  1'iC/uOLt 
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CHAPTER  X 

SEGi'jLATS 


Tne  segments  n.ooule  is,  of  course,  resccnsi  tie  for  the 
management  01  segments,  the  logical  storage  units  of  Hultics. 
»<itnm  tms  r.,ouulc,  segments  are  identifies  by  uio  only.  The 
local  process  view  of  segments,  where  segment  numbers  arc- 
useu,  is  defines  by  tne  aoor ess_seaces  r.coule  describee  later. 

At  segment  creation,  a visibility  access  level,  a volume,  anc 
a quota  cell  must  oe  spec  1 f leo . The  new  segment  resides  or. 
the  specifies  volume  ar.d  cnarges  its  pages  to  the  specified 
quota  ceii  (vnicn  must  also  reside  cn  tne  same  volume).  The 
access  level  ci  tne  new  segment  is,  by  necessity,  equal  to 
cnat  of  its  associated  quota  cell. 

ac  limit  is  placeo  cn  tne  number  of  segments  that  can  be 
created  cn  a giver,  volume.  In  practice,  however,  a volume 
table  or  contents  (VTCC)  entry  will  ce  required  for  each 
seamer.t.  Inus,  tne  VTuC  represents  yet  another  instance  of 
tne  snared  finite  resource  problem.  At  present,  hultics 
provides  r.o  direct  means  for  controlling  the  consumption  of 
vTbC  space.  Limits  cn  tne  size  or  directories  provide  ar. 
indirect:  form  oi  control,  but  this  is  entirely  inadequate, 
uven  it  security  considerations  arc  ignored,  there  still 
exists  a serious  problem,  in  that  a single  user  cannot  be 
prevented  tram  consuming  an  arbitrarily  large  number  of  VT'CC 
entries. 

One  possible  solution  to  tnis  problem  is  to  introduce  the 
concept  oi  segment  quotas.  Tne  proposed  quota  cell  mechanism 
alreauy  maintains  a segment  reference  count.  By  enforcing 
limits  cn  tne se  segment  counts,  tne  use  of  VTCC  entries  could 
be  controiicu.  Tins  implies,  however,  an  additional  burden  on 
tne  user.  .men  moving  quota,  tne  user  would  need  to  specify 
not  only  tr.c  amount  of  page  quota  to  move  but  also  tne  amount 
ct  segment  quota. 

functions  ere  defined  tor  reaoing  anc  writing  the  contents  of 
segments.  These  functions  have  certain  siae-ef foots , as  well. 
Initially,  all  woros  of  a segment  have  a value  of  zero. 

Tne  segments  mcoule  maintains  a page  map  (i.c.  a record  of 
existing  pages)  for  cacn  segment.  Initially,  a segment  has  r.c 
existing  pages.  A page  is  created  the  lirst  time  a wore  of 
tne  page  is  written.  The  page  remains  in  existence  until  the 
segment  is  truncated  to  a size  tr.at  excludes  the  page. 

Tne  treatment  ot  zero  pages  differs  from  that  of  current 
.lultics  in  two  respects.  First,  reading  from  a zero  page  ooes 


4 1 


not  cause  the  page  tc  be  created.  Second,  zero  pages  are  net 
automatically  oeletec  at  tne  time  tney  become  cancicates  for 
removal  trom  main  memory. 

Tne  lirst  uitference  is  motivated  cy  security  considerations. 
Tne  page  map  for  a segment  has  the  same  access  levei  as  the 
segment  itseiL.  Therefore,  a user  having  rcac  access  to  a 
segment,  out  not  write  access,  cannot  be  permittee  tc  modify 
tne  page  map.  nence,  reaming  a nonexistent  page  cannot  be 
slioweu  to  cause  the  page  to  be  crestec.  Unfortunately,  this 
restriction  causes  a aifticuit  problem.  The  solution  appears 
to  require  a cnange  to  tne  Multics  processor. 

one  proposal  suggests  tnat  cage  table  words  contain  a 
rauit-cn -write  bit  that  can  ue  useo  to  oetect  the  first  time  a 
page  is  written  [SB3]  . All  cage  table  worcs  tor  zero  pages 
couio  tnen  we  airectcu  tc  a single  zero  page.  Only  wnen  an 
attempt  is  maae  to  write  a zero  page  would  a new  page  be 
created . 

Inis  idea  can  oe  carried  a step  further  by  navir.g  a 
‘•zero-page"  bit  instead  cf  a iault  — on— write  bit  in  each  cage 
taoie  were.  ine  zero-cage  bit  would  imply  tnat  any  attempt  to 
reao  from  tne  page  snoulo  always  return  a zero  witnout  any 
fault  cr  memory  reference.  An  attempt  tc  write  the  page  would 
cause  a page  fault,  as  usual. 

hardware  cnanges,  cf  course,  are  to  be  avoided  -wherever 
pcssiwle.  in  tnis  case,  a hardware  change  seems  unavoidable, 
aowever,  an  interim  solution  is  possible  that  avoids  modifying 
tne  processor.  Tne  effect  of  tne  iault-on-write  bit  cculc;  oe 
simulated  cy  a special  memory  box.  This  memory  ccx  woulc  have 
no  real  storage.  It  would  simply  return  a zero  ior  eacn  re-au 
operation  ano  would  cause  a fault  on  eacn  write  operation. 
The  kernel  would  arrange  for  tne  page  table  words  of  zero 
pages  tc  always  address  this  special  memory  cox.  Dedicating  a 
memory  port  to  tnis  special  memory  box  essentially  wastes  a 
portion  ct  tne  available  absolute  aouress  space.  Tnis, 
nowever,  uoes  not  appear  to  be  a serious  crawbacK  since  r.c 
multics  system  yet  contemplated  requires  the  maximum  amount  of 
main  memory. 


Tne  secono  difference  in  tne  treatment  of  zero  pages,  i.e., 
tne  elimination  oi  automatic  deletion  of  zero  pages,  is  net 
motivated  oy  security  considerations.  Rather,  this  difference 
is  motivated  wy  a desire  to  avoid  introducing  niciaen 
mecnamsms  into  tne  kernel  top-level  specification.  In 
cui  rent  i-iultics,  tne  deletion  or  zero  pages  occurs  at  the  time 
a page  is  selectee  ter  removal  from  main  memory.  This  time 
cannot  oe  predicted  using  only  knowledge  available  at  the  user 
interlace  ano,  consequently,  gives  rise  to  non-cetermin istic 
anu  sometimes  anomalous  oenavior.  Such  behavior  depends  upon 
ractors  suen  as  the  size  of  main  memory  which  are  not  visible 
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in  tne  top-level  specif icat ion 


Tne  consequences  or  eliminating  automatic  oeletion  of  zero 
pages  seem  toleracle,  it  not  desirable.  i'nis  change  is  r.ot 
incompatible ; it  should  r.ot  cause  existing  programs  tc  stop 
wording.  It  will,  however,  cause  storage  charges  tc  ce  signer 
icr  segments  maintained  by  programs  tnst  oelicerately  or 
inadvertently  acccmplisn  page  deletion  tnrougn  zeroing  rather 
tnan  truncation.  hopefully,  tne  numcer  of  suen  segments  is 
small  ar.u  tne  programs  tnst  maintain  them  car.  be  changed 
eventually.  At  tne  same  time,  tnis  change  has  the  advantage 
ot  making  it  possible  to  uetermir.e  tne  size  cf  a segment  with 
certainty.  inis  is  not  new  tne  case  cue  to  the  previously 
uescr iceu  non-deterministic  behavior  ci  tne  pacing  mechanism. 


Two  otner  segment  attributes  are  tne  date-time  usco  (dtu)  anu 
tne  uate-time  modified  (atm).  fcr  reasons  cescrioed  oclow, 
tnese  two  attributes  are  maintained  in  a different  fashion 
and,  consequently,  have  somewhat  different  meanings  in  the 
kernel -cased  i.uitics. 


In  current  l.ultics,  the  otu  anu  ctm  for  a segment  arc  uccatec 
c-acn  time  tne  vlbC  entry  for  tne  segment  is  updated.  This 
occurs  wnen  a segment  is  deactivated.  It  also  occurs  men,  in 
searcning  tne  active  segment  taclc  for  a segment  tc 
deactivate,  a segment  is  found  witr.  a page  table  that  has  been 
modirieu.  This  metneo  of  updating  relies  on  niciaen  mechanisms 
ano,  rrom  tne  user’s  viewpent,  results  ir.  non-oeterm.inistic 
anu  otter,  anomalous  behavior.  Such  benavicr  depends  upon 
iactors  whicn  are  net  visible  in  tne  top-level  specif icatier. 
suen  as  tne  size  cf  tne  active  segment  facie. 

In  croer  tc  avoid  introducing  nicuen  mechanisms  into  the 
top-level  Kernel  specification,  a new  method  of  updating  ctu 
anu  c ti.i  is  proposed.  Ideally,  ctu  ana  ctm  snoula  ce  unacted 
on  eacn  segment  reference.  Since  tnis  is  net  possible, 
However,  cnc  Kernel  maintains  two  indicators  called  the  '‘usee" 
ar.u  "moairieo"  flags.  A function  is  provided  to  up-cate  ctu 
anc  dtm  cased  on  tne  settings  oi  the  usee  and  modified  flags. 
As  will  De  seer,  in  tne  address  spaces  moculc,  tnis  fur.cticr.  is 
lr.voKeu  automatically  at  tne  time  a segment  is  terminated.  It 
is  also  invoked  automatically  tor  all  initiatcc  segments  at 
tne  time  a process  is  terminated.  ..nere  greater  accuracy  is 
required,  tne  updating  function  can  tc  ir.vckec.  explicitly, 
inis  wouic.  ailew  an  editor,  tor  exam.plc,  tc  update  ctu  arc  dtm 
after  writing  out  a cutter. 

A request  to  update  utu  end  atm  is  nonorec  cr.ly  if  the 
corresponding  used  ana  m.oaitica  flags  nave  been  turned  on. 
Ine  m.Odiiicu  flag  is  set  eacn  time  a segment  is  written.  In 
principle,  tne  used  ilsg  should  ce  set  eacn  time  a segment  is 
read  or  written.  Unfortunately,  security  considerations 
promcit  tnis  interpretation  of  tne  used  flag.  The  access 
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level  cl  the  useo  flag  is  equal  to  tne  access  level  of  the 
segment.  i’nereiore,  just  as  in  the  case  of  the  page  map,  a 
process  witn  only  reao  access  to  the  segment  cannot  be 
permittee  to  cnange  the  useo  flag. 

In  otter  to  provioe  at  least  some  support  for  the  dtu 
attriouce,  ana  yet  not  violate  security,  tne  kernel  offers  a 
compromise.  ine  uscc  rlag  is  always  set  by  write  operations 
on  a segment.  For  reao  operations,  the  used  flag  is  only  set 
if  tne  process  access  level  equals  tne  segment  access  level. 
L’ncer  tnese  ccnaitions,  there  is  nc  violation  cf  security. 
Thus,  tne  otu  shoulo  be  interpreteo  as  the  last  time  a segment 
was  useo  cy  a process  cf  the  same  access  level.  bote  that  in 
single  access  level  systems,  tnis  dirference  causes  no  cnange 
to  tne  meaning  cf  ctu. 
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AouoLu  segments 


TitLo 

level_nuiTicec  : {InTEGot\  In  | u <=  In  Au.C  In  <=  rr.oxln}; 
category  set  : mCiutv_CF  3CCLSA:!  cs  | LENGTH  (cs)  = cc  size } ; 
£ccess_ievel  s jii.uli  (level  numoer  sin; 

category  set  scs; 
level_number  iln; 
category  sc  t ics ) f 

^roctss  Liu  i I.ri  LvjlK  ; 

voru..,e_uiu  : 1..  i LGEn  ; 
quota  ceil  uio  * inTLoLh.; 
segment  uiu  : buLurh; 

seg...er.t  o r t se  t • [lux luli\  sc  | o ^ = so  An o so  = max  offset}; 
itacnine  woru  z I t.*j. , 

pa^e  _nu f..aer  : {INTEGER  pn  I i <=  pn  AUD  pn  <=  (max  cf f set+i)  /paae  size 


^ i * O 


process  uio  procure; 
voiu.re  uio  vciuiu; 
quota  coil_uio  occiu; 
segment  uio  seguia; 
access  revel  ai,  val; 
segment  oiiset  onset; 
taciune  wore  woro; 

P ag e nur.ioC r uageno; 

iuIlull  time ; 

i i't  X L. Vj  i_.X\  1 f 

VLwi'Oi\_oc  tt; 

v Li X O i\  or  dL f 


f Ax\Ar»b  I c.  hS 

segn.ent_onse t r..ax_crtset  § (rr.axitr.ur;  segment  ctfset)  ; 

a ^ e _n ur.oe r u . a x pageno  .?  (maxi mum  page  numoer  ) ; 

IuTouLk  page_size  $>(numer  of  worts  in  a cage); 

bLtiui'i  lu.iu 

inru.ot.tv  totai  pages  ( seg uiu  ; pageno)  IS 

CHx\LIi«rtLIXi  ( { 1 | x >=  pageno  ANE  i <=  .max  paaer.c  APE 
n_page_exists (seguro , i)j); 

juuLlAv.  unmount cu  volume  (procuic ; vciuiu)  IS 
It  *n_vcl  j-ounteu  (voluio)  THEN  Tt-LL 

uL so  ~n_  reau  ailoweo  (n_proc_tr  ustco  ( procuic ) , n prcc  ai  ( prccuir. ) , 
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n_vol_min_al (voluid) ) ; 

uuollA.'I  no  quota  cell (procuio;  voluic;  qcuio)  IS 
IF  ~n_qc  exists (voluic , qcuid)  TtiEi'i  TRUE 

ELSE  ~n_reaa_allowea (h_proc  trusted (procuic) , b croc  cl (procuid) , 

h_ac_visibility_al (qcuid) ) ; 

iid-OLEA^  cutsiae_qc_ levels (qcuio ; val)  IS 

~n_write_alioweG (FALSE,  h _qc_ v is ibil i ty_al (ccuic) , val)  OR 
~h_writc__ailowec  (FALSE,  val,  n_cc_al  (qcuio)  ) ; 

doOLEAx  write_not_allowec (procuid;  al)  IS 

~h_write_allcwea (h_proc_ trusted (procuid)  , n_proc_al  (procuic ) , ai) 

liooLLAu  no_seg.Tier.t  (procuic;  veluid;  sequic)  IS 
It  ~n_seg_exists (voluid , seguid)  THEx  TRUE 

EEo l ~h_r eao_ al lowec (n_ pr cc_tr us teo (pr ocu id ) , h prec  al  (procuid)  , 

n_seg  visibi 1 ity_al ( scguicY) ; 

uouLtAi*  reao_not  all ewee  (procuio;  al)  IS 

~d_reaa  _al lowec (n_prcc_tr us  tec (procuic ) , h_proc_al (procuic)  , al); 


c..\Tur.xALKLt  S 
r ci  CC  x : 

vtuii  reac_clocx()  ->  ti;r.e; 

Cn/tu.  get  uic()  ->  seguic; 

tiw.,  access  levels: 

le  vel  _r.ui.rcer  rax  ir.  S (rr.aximu.T.  level  nuo.oer); 


1*^1  l. sj l cs  3120  >>  (category 

set 

size) 

v *r  uti 

3 I 6.  a C.  al  Io'aCG  ( c ; 2 1 J 

al) 

* > o ; 

v f'0.< 

r*  writs  all  owco  ( c ; a j. 

; ai ) 

->  o 

crccc 

V r 

a j:roc  al  (procuic)  -> 

al ; 

vtU«  n_prcc_trustec (procuic)  ->  t; 
tuc.  vciu.T.es: 

vrd,  n vol_miR_al (voluic)  ->  al  ; 

V r U x n_voi_mcunteo (voluic)  ->  c; 

rt-.cii  quota  cells: 

v t ox  n _gc  exists (voluic ; qcuio)  ->  c; 
vf  o*«  n qc  v isioility_al  (ccuic)  ->  ai  ; 
vtT..  n cc  al  (qcuio)  ->  ai; 
uFL..  c.iange  qc  rets  (qcuio  ; i); 
orb..  cnange_qc_pages_useu  (qcuic ; i); 


H U 


r u.,CTIo.io 


CVrliA  cr eateseg ( val ; voluic;  ccuic ) [ procuic  ] ->  seguic; 
:?  (creates  a new  segment) 

La  Cl.PT  low  a 

unmounte-ci  volume  (procuiu , voluic)  ; 
no_auota_cell (procuic , voluic,  ccuic); 
outsice _cc_levels ( ccuic , val); 
wriccnot  alicwcu (procuic , val); 

EFFECTS 

seguiu  = £rFuCTS_GF  get  uio(); 

'h_seg  visibility_al (seguiu)  = val; 

* n_seg  ac ( seguio ) = ccuic; 

‘ n_seg  exists  (vcluiO  , seguic)  = li-UE; 
ErfuCTS_OF  cn&nge  cc  refs(ccuio,  i); 

vF u.(  n seg  exists  (voluic ; seguic.)  ->  o; 

^(true  it  segment  exists) 

INITIALLY  c = r’ALic; 

uu  n seg  visioilityal (seguic)  ->  al ; 

+ [returns  acces-  level  ot  segment  creator) 
uIuLuii ; 

I..  IIIALlY  al  = ? ; 

v t u..  seg  visicility_al  (voluio;  seguic)  [procuiu]  ->  al; 

E (external  ter...  ot  n seg_visiti 1 ity_al ) 

tACLr'l  lUi.u 

unmounteei_volume  (procuiu  , voluic)  ; 
no  segment (procuiu , voluio,  seguic); 
uuwIVA'iiou  n seg  visioilityal  (seguic); 

vtu w u seg_ai ( seg uiu ) ->  ai ; 

j (returns  access  level  01  segment) 

uiocut. ; 

uli\I I vlv  n cc  ax  (a  seg  cc  (seguiu)  ) ; 

vim.,  seg  ax  (voluic;  seguiu)  [ procuic ] ->  al  ; 

E (external  term.  c£  n_seg_ai) 

LAU llr'jL  xOhJ 

unmount eo  volume ( procuic , voluic); 
no  segment (procuic , voluio,  seguic); 
o t k I V / 1 i 1 0 w n seg_ai (seguic) ; 

Vo,,.  n_seg  cc  (seguiu)  ->  qcuiu; 

v (returns  quota  ceil  uiu  or  segment) 

dluoLil ; 

IwIlTALLY  qcuiu  = ?; 

vco-  seg  cclvoiuiu;  seguic )[ procuiu j ->  qcuiu; 

E (external  form,  ot  n seg  cc) 

bACLpi  iCi.G 

unmounteu  volume  (procuic  , voluio); 
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nosegment (prccuid , voluid,  seguic); 

reau  not_allcwed ( crocuiu , h sec  visibility_al (seguid) ) ; 

EERI NATION  h seg  qc(scguic); 

cr'u.M  uelete  seg(vciuic;  seguid ) l procuid J ; 

E (oeletes  a segment) 

LEFIdl  I10N6 

access  level  al  IS  n seg  visibility  al  (seguid) ; 
quota  ceil  uio  qcuio  IS  n seg  cjc(seguic); 

LAuLpliul.J 

unmountec  volume (procuic , vcluic); 
no  segment (procuid,  voluid,  seguic); 
write  not  allowed (procuid , al); 
wF r LC'IS 

EFFECTS  OF  truncate  seg (voluid,  seguid,  o,  procuid); 
n_seg  exists (voluid , seguic)  = FALSE; 

EFFECTS  OF  cr.ange  cc  refs(qcuid,  -1)  ; 

CFLd  write  seg (seguic;  offset;  wore); 

S (writes  a wore  of  a segment) 

LLF  IdlTICI'iS 

INTEGER  pageno  IS  (offset  + page  sice)  / cage  size; 

EF FeCTS 

1 n seg  usee (seguic)  = TRUE; 

'nseg  mco ir ieu ( seguic ) = TRUE; 

'n  seg  contents ( seguic , offset)  = word; 

’h  page  exists (seguic,  pageno)  = TRUE; 

~n  page  exists (seguic , pageno)  => 

EFFeCTSGF  change_qc  pages  useci(h  seg_qc  (seguic)  , 1); 

CVcod  reac  seg (procuic;  seguid;  offset)  ->  word; 
v i rc ato  a wore  of  a segment) 
lc r e C i S 

n write  aliowee (FALSE , n croc  al (procuic),  h seg_al ( seguid ) ) 

= > 'a  seg  usee  (seguic)  = TRUE; 

were  = n seg_contents (seguic , offset); 

vru».  n_seg  contents  ( seg  uia ; offset)  ->  wore; 

.?  (returns  a wore  ci  a segment) 

r.  1 uL  cd  ; 

1 in  I T 1 h L L 1 wore  = 0; 

Vr'UiM  n cage  exists  (seguic ; pageno)  ->  c; 

■?(truc  if  page  exists) 

u 1 uL  Lit  } 

INITIALLY  L - fALSE; 

v.-u  existing  pages  (voluid ; seguia)  ( procuic  ] ->  cmap; 

S (returns  oit  map  oi  existing  pages  of  segment) 
e.\CeF1  iti.j 

unmountec  volume (procuic , voluiu); 

r.o_segment  (procuic , voluiu,  seguia); 

reac  not  aiicwec (procuic , h seg  al (seguic)); 


•i  o 


eEkIVATIGN  VECTOR  (kOt\  i ci\OM  1 TO  ir.ax  pageno: 

n pace  exists ( seguia  , i) ) ; 

OFLa  truncate  seg (voluio;  seguio;  pageno)  [crccuid]  ; 

S (truncates  a seg.r.ent  tc  pageno  pages) 

LaClFT I OaS 

unir.cunteu  volume  (procuic  , voluio)  ; 

no  segment  (procuio  , voluio,  seguia); 

write  noc  ailcweo (procuio , n seg  al (seguio)); 

Lr  Fc.C'lA> 

FoAALL  i I i > pageno  AMO  i <=  max  pageno  : 

n page  exists (seguio , i)  = FALSE; 

EfFECiS  OF  cnange  cc  pages  used (n  seg  cc(seguic), 

-total  pages ( seguio , pageno  + 1)); 

POinALO  i I i > pageno  * page  size  A 00 

i <=  max  pageno  * cage  size  : 

'n  seg  contents  (seguio , i)  = U; 

vcu.  n se-g  useo  ( seguio)  ->  s; 

>(truc  ir  seg.r.er.t  has  seen  used  since  last  reset) 

rilbbOA  ; 

1a X x X A L L 1 l = rALjo; 

vttn  a seg  moaitieo (seguia)  ->  c; 

S(true  it  segment  nas  seen  moo i l i eo  since  iast  reset) 

;1 1 oo o.» ; 

luITIaLLi  b = FALSE; 

vtun  a seg  otu  (seguio)  ->  time; 

^ (returns  oate-time  useo  ter  segment) 

ii  1 U/  L.i ; 

lull  IALL1  ctii.e  = u; 

v r La  n_seg  otir.(seguio)  ->  time; 

S (returns  uate-tir..c  mooitieo  tor  segment) 

UlbULlt  / 

IaII'IAlLY  time  = U; 

vtu  seg  otu_otra  (voluio ; seguio)  l procuio]  ->  tt; 

$ (external  term  or  n seg  otu  ano  n seg_ctm) 
b b F I il  I i 1 O A S 

INTEGER  otu  Is  IF  h seg  used (seguio)  THEN  read  c1gck() 
cLSl  h_seg_ctu (seguio) ; 

li/IEOLr.  utm  IS  IF  n seg_moo i £ ieo  (seguio)  THE:';  reac_clock() 
ELSs  n seg_ctfi.  (seguia) ; 

b AOtr'i  1 0 ao 

unmounteo  vcl ume (procuio , voluio); 
no_scgmer.t  (procuio  , voluio,  seguio); 
reao  not  alloweo (procuio , n seg_al ( seguio ))  ; 
a o i\  1 Wt  1 1 c a v l\.  Ai\  (otu,  atm)  ; 

Jr oa  cnange  otu  otm (seguio); 
i>(upoates  otu  ano  otm) 


LFFLCTa 

n_seg_used (seguic)  =>  'n  seg_dtu (seguid)  = rcac_clock ( ) ; 
n _seg_ir,ouit  ieo  (seguic)  =>  ' h_seg_atm (seguic)  = read_clcc;<  { ) ; 
'n_seg_usec (seguid)  = FALSG ; 

1 n_seg  jr.ocii  iec  ( seguic ) = FALSL; 

Or  Li.  upuate  c tu_c t.Ti  ( voi uid ; seguic) [ procuic ] ; 

.?  (external  lorn.  of  cnange  _ctu_ctir.) 
callFTIGuS 

unir.ountec_volun;e  (procuid , voi1.  Lc)  ; 
no_segment (procuic , voiuic,  seguic) ; 
wr ite_not_allowec (procuid , h_seg  al  (seguid)); 

LF  r LC'i'S 

Lt  r £CTo_GF  char.ge_ctu_ctm  (seguid)  ; 


L..L  ..ouuLl 
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CriAP'lLu  XI 


t\ lj u i\ t> S 5 CPACLS 


ine  accress  spaces  module  supports  tne  binding  of  segment 
numbers  to  segments  within  a process  as  well  as  the  granting 
ano  revoking  cf  current  access  to  segments . Tnis  mocuie  also 
provides  Kernel  interface  functions  for  reacing  anc  writing 
segments . 

‘ine  Dinning  of  a segment  number  to  a segment  is  accomplished 
oy  tne  “assign  segno"  function.  dote  tnat  the  kernel  docs  net 
select  tne  segment  numcer . Tnis  selection  is  performer,  by 
tne  supervisor,  tnus  relieving  the  kernel  of  a numcer  or 
ooo.<Keeping  cncres.  Information  about  assignee  segments  is 
Kept  m a per-process  tade  called  tne  known  segment  tacle 
iKbt)  . ine  KSt  is  represer.tcci  by  a collection  of  v-f unctions. 

Tne  assignment  ci  a segment  numcer  to  a segment  cces  not  make 
tne  segment  Directly  accesside.  This  is  accor. dished  cv 
anotner  function  calico  “give  access"  for  union  the  caller 
speciries  tne  access  m.cae,  ring  orackets,  call  limiter,  ar.c 
maximu.G  ier.3 tn  of  tne  segment.  The  requested  access  mote  is 
mouiiieo,  11  necessary,  cy  tne  kernel  to  conform  to  access 
lever  restrictions.  bote  tnat  any  process  can  grant  itself 
access  cc  a segment  in  tnis  fashion.  However , it  is  expected 
mat  tne  supervisor  will  control  tne  use  of  tne  give  access 
runcticn  sc  as  to  enforce  tne  Lultics  access  ccntrcl  list 
(nCL)  policy.  Also,  the  supervisor  will  enforce  the  ring 
crocket  policy.  Tne  kernel  insists  only  tnat  segment  ring 
bracKets  ce  outsioe  tne  kernel  ring. 

A rur.ction  is  previaeo  to  revoke  tiie  current  access  of  ali 
processes  to  a given  segment.  Tnis  function  can  be  usee  cy 
tne  supervisor  tc  force  all  processes  to  recompute  access  tc  a 
segment  alter  an  ACL  has  ceen  cnangeo.  Cr.ce  access  has  been 
revekeo,  sucsequent  references  tc  tne  segment  will  cause  an 
exception.  inis  exception  is  implemented  as  a tault  that  will 
oe  directed  to  the  supervisor.  In  handing  this  fault,  tne 
supervisor  will  calculate  the  access  of  the  faulting  process 
tc  tne  segment  arm  tnen  invoxe  tne  give  access  function. 
After  tnis,  execution  can  be  resumec  from  tne  point  at  which 
tne  fault  occurred. 

Tne  address  spaces  module  includes  the  revoke  vol  access 
runcticn  wnich  is  niduer.  from  tne  kerr.el  interface.  At  the 
time  a volume  is  demounted,  access  to  ali  segments  on  tne 
volume  is  revoKCd  oy  use  of  this  function.  Thus,  if  tne 
volume  should  later  oc  remounted,  all  processes  will  bo  forced 
to  recompute  access  to  segments  on  tne  volume.  Ibis  permits  a 
user  to  cnange  tne  ACL  of  a segment  on  a demounted  volume  and 
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ce  assuree  tnat  nis  cnange  will  take  effect  as  soon  as  the 
volume  is  re  i.tO  U I"1 1.  G C • 

luree  acscract  functions,  calico  "reao",  "write",  and  "fetch", 
are  specifier,  in  tne  aaoress_spaces  mocule.  These  functions 
oo  not  cirectiy  correspond  to  any  actual  kernel  interfaces, 
earner,  tney  represent  the  memory  reference  operations 
asscciateo  witn  whole  classes  of  machine  instructions.  For 
example,  tae  reao  function  is  inoicative  of  all  load 
instructions  whereas  the  write  function  is  inoicative  of  all 
store  instr uctions . Tne  fetch  function  is  used  by  the 
acstract  machine  interpreter  to  feten  instructions. 


d2 


i-iuDuEo  auures 


spaces 


1 i'rc,S 


ievel_nuiaoer 
category  set 
access  level 


: {INTEGER  In  | o <=  In  AND  In  <=  max  In}; 

: { V£CTCi\_Gr  BOOLEAN’  cs  | LENGTH  (cs)  = cs_size} 
: SXNuCT  ( levelnumber  sin; 

categcry_set  scs; 
level_r.umcer  iln; 
categcry_set  ics); 


ptoccss_uio  : 1 N T L E t\ ; 
vciumeuie  : INTEGER; 
qucta_cell_uio  : INTEGER; 
segment  uic  : INTEGER; 

access_ir.cue  : { v’ECTCi-.  _uF  SGCLEA..  am  I LENGTH  (an1.)  = 3}; 
ring  nuir.oer  : {INTEGER  rn  | u <=  rn  AWL  rn  <=  rax  ring}; 
rir.g_uracK.ets  : { \/ECTGR_CF  r ing_numccr  rb  | LENGTH  (rb)  = 3}; 
call_i imiter  : (lNTLGLn  cl  | -1  <=  cl  AND  cl  <=  max  cl}; 
segmen  t_nu;..oer  : {IWTEGEn  sn  | u <=  sn  AND  sn  <=  max  segno}; 
segmer.t_cl:rset  : {INTEGER  so  | u <=  so  AND  so  <=  ii:ax_of f set } 
macnir.e  weru  : L.TEuEx; 


Due  LAr  .«i  1GNS 

process  uio  procuio,  croc; 
volume  uio  voiuic; 
quota  ceil  uio  q c u i o ; 
ot,...tnt  uio  ueg u iu  ; 
access_ievei  al; 
access  mouc-  .uooe,  giver._ir.ooe; 
r ing_nuiriuer  ring; 
r ing_oracKets  ro; 
call  limite-r  cl; 
segment  numcer  segno; 
segment_cr iset  oriset; 
inacnir.e  wore  wore; 

uOuLu.u*  u ; 

INI  uu  ut\  1 ; 


RArvANuloKS 

r ing_nui.-.oer  xernel_ring  3{nighest  ring  usea  by  Kernel); 
ring  _ numcer  max  ring  ? (maximum  ring  numcer); 
call  _i  irr.iter  max  cl  $ (maximum  call  limiter); 
segmer.t  nur.oer  r.;ax_segno  S (maximum  segment  r.u.PLer); 


D l : 1 a 1 1 1 J 

access_mcu£  null  moo e IS  vuGioi\  (FALSE,  rALou,  FALSE) ; 


access_moae  rewmooe  IS  VECTOR  (TkUL,  Tt%UE,  Tt-.UL) 

access  moce  remoue  IS  VECTOk  (TKUL,  TKUL,  FALSE) 

owoLuA...  wr ite_not_alloweo  (procuio;  al)  IS 

~h_write_ ailoweu (n _proc_tr us teu (prccuici)  , n_ 

douLlmj  unmounteo  volume  (procuic ; voluia)  IS 
If  vol_n.ountea  (voluio)  THtil  TKUL 
l.LSo  ~n_reac  allov/ec  (n  croc  tr ustec  (procuid) 

n_vol_min  al  (voluio) ) ; 

douLlAw  nc_segment  (procuio ; voluio;  seguic.)  13 
IF  ~n _seg_exists (voluio , scguic)  TtiEri  TKUE 
LLSa.  ~ti_reaa  allcweo  (n_proc  trustee  (procuia) 

n_seg_visioility_el (set 

oocLlA.i  segno _in_use  (procuio ; segno)  IS 

'(n  xstseguia (procuio,  segno)  = ?)  ; 

LauaLA.,  unusea_segnc  (procuio;  segno)  IS 
n_kst_seguiu (procuio,  segno)  = ?; 

invalio  mcce  (ncoe ) IS 

'(mode  = null  ir.oue  C.\  mooellj); 

/ 

oeOLEAK  invalio  r ing_cr ackets ( r b ) IS 
(kernel  ring  < roll]  A:,s 
r o [ 1 J < = r o 1 2 j A:.u 
ro  U j <=  ro  [ 3 J ) ; 

-aeloui  no_writc_permission (procuio;  ring;  segno) 
'(a  kst  moce (procuio , segno) [3]  AbD 
ring  <=  n_ks t_ru ( procuio , segno)  11)); 

owoLurv.,  ncrcaopermissicn (procuic;  ring;  segno) 

' (n  Kst  moce (crocuid , segno) (1}  AKL 
nn^,  <=  n Kst  ro  (procuio,  segno)  [a]  ) ; 

owwLtAo  no_execute  per  mission (procuio;  ring;  segn 
' (n_KSt  n.ooc  (procuic  , segno)  lb]  Ai«l 

ring  <=  n K3t_rb (prccuib , segno)  [2]  ALL 
ring  >=  a_kst_ro (procuic , segno)  [1)); 

uatLLH..  unoetineu  access  (procuio;  segno)  IS 
n x s t access  oefineo (procuio , segno); 

aucLana  o u t _o i_ocunos (procuio ; segno;  offset)  IS 
ofiset  > n \s t _max_c ifset (procuio,  segno); 

oouLLA^  page  quota_over f low (qcuio ) IS 

n_qc_pages_useu (qcuiu ) = h qc_pages (qcuia ) ; 


procal (procuic) , al) 


, P_prcc_al (procuio ) , 


, hprocal (procuio) , 
uic)  j ; 


lb 


o)  IS 
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t.Xit.t\i»ALfvLFS 


t tw.  access_ieveis: 

level  numer  r.axin  S (rcax irr.urr.  level  number); 

IuTLuEfe  C5  size  $ (category  set  size); 

VYUb  n_reao  aiiO'.vec(o;  el;  al)  ->  o; 
vrua  n write  allcweo(o;  al ; al)  ->  c; 

VrU*.  n_reao_write  ailowec(b;  al;  al)  ->  e; 

nvO.i  processes: 

VrUa  n_prcc  exists  (procuio)  ->  b; 
v r Ui»  n_prcc  al  (procuic)  ->  al ; 

VrUX  n proc  trustee ( procuic)  ->  b; 

ci\o/i  voiui.es: 

VrbY  n_voi  .r.ountec  ( vol  uio ) ->  b; 

VrU»  n_vol_r.:in  al(vcluio)  ->  al; 

c quota  colls: 

vrua  ncc  pages (qcuio)  ->  i; 
v r’Ui'f  h_qc_pages  useo(qcuie)  ->  i; 

r <\un  segments: 

segment  otiset  rax  oifset  $ (maximum  segment  ctlsct); 
Vr'uX  n segexists (voluic;  seguio)  ->  b; 

VrUi  n_seg_visioiiity_al (seguio)  ->  al; 

Vr'o.«  r.  seg  _al  ( seg  uio ) ->  al; 
vr'b.i  n seg  qc ( seg uio ) ->  qcuic; 

OFu.'i  write  seg(seguiu;  onset;  were); 

u'vrb.<  reaoseg (procuic;  seguio;  onset)  ->  wore; 

uf  Li.,  cnange  otu  oti.(seguiu)  ; 


c unv.Ti'oAj 

or  o.x  assign  _seyno  ( vol  uio ; seguio;  segno)  Iptocuic) ; 
v (assigns  a segment  nu...oer  to  a segment) 
t,  XCr-tTlOi^S 

segno_in_use (procuic , segno); 

Lr  FlCTo 

• n_xst_voluio (procuic  , segno)  = voluid; 

‘ n_kst_ seg uid (procuic , segno)  = seguid; 

* ft  Kst_access_cef inec (procuic , segno)  = FALSE; 

vruw  (i  kst  voi uio  (procuic ; segno)  ->  voluic; 

» (returns  voluic  ci  assignee  segno) 

lilOcLw ; 

IwlTlALDf  voluia  = ?; 

va.<  KSt_vcluio  (segno)  [procuic)  ->  voluic; 
b (external  form  of  n kst  voluic) 

LaCl.  tr'XI  Ob’S 


M 


unusea  segno (segno) ; 

uEkIv'AI'IOn  n kst_voluid (procuio , segno); 

vtu.-,  n_kst_seguiu (procuio ; segno)  ->  seguid; 

^(returns  seguio  of  assigned  segno) 
nILDLN ; 

INITIALLY  seguio  = ?; 

\zt  u.j  .<st_seguio  (segno )[  procuio ] ->  seguio; 

:?  (external  form  of  n_kst_seguic) 

LXCc.P'1  I GAG 

unused  segno (procuio , segno); 
potvl  VAilGts  n kst  seguio  (procuio , segno); 

vtuN  a NSt  access  oef ineu ( pr ocu id ; segno)  ->  b; 

*(true  ii  access  oetxneu  to  segment  for  process) 

H1oL_l.  ; 

INITIALLY  o = FAL3l; 

ovru.'t  give  access  (segno ; off  set;  moot;  rb;  cl)  [procuio]  ->  giver,  mode; 
3 (gives  a process  access  to  a segi'.ent  and  returns  given  mooe) 

'O  t i.<  1 ±.  I w ii  J 

volume  uio  voiuiu  IS  h kst  voluio  (procuio , segno); 
segment  uic  seguio  13  n kst  seguio (procuio , segno); 
access  levei  al  13  n eeg  al (seguio); 

ECGLaAN  reaoable  13  n reac _allowed  (h  prcc  trustee (procuio)  , 

n pr cc  al(procuid),  al); 
EGCLEAo  writaolc  13  h reao  write  allowco  ( 

n proc  trustee (procuio) , h croc  al(prccuio),  al); 
access  mooe  max  m.oce  13  IF  writable  THEN  rev;  r..oce 
ELSE  IF  reaoable  TGLN  re  mcoe 
LLSC  null  mooe; 

laCuFTICiw 

invalio  mooe (mooe); 
invalio  ring  br ackets ( rb) ; 
unuseo  segno  (procuio  , scqr.o); 
unm.ounteu  volume  (procuio  , veluie)  ; 
no  segment (procuio , voluid,  seguid); 

LrYtCTa 

given_mooe  * vECTOA  (FGF  i FACtl  1 Tu  3 ; 

mode[i]  AND  max  modefi]); 

’n  kst  max  offset (procuio , segno)  = otfset; 

‘n  kst  mcoe (procuio , segno)  = given  mcoe; 

‘h  kst  to(procuio,  segno)  = rb; 

‘n  kst  ci (procuio,  segno)  = cl; 

*n  Kst  acccss  oef  ir.eo  ( procuio  , segno)  = TF  G £ ; 

Vtu.\  n KSt  max  of  t se  t (procuio ; segno)  ->  offset; 

3 (maximum  offset  tnat  car.  cc  reierer.ceo  in  segment) 
nlbobW ; 

InIIIALoi  oitset  = ?; 

vro.x  *st  max  onset  (segno)  [procuio]  ->  offset; 

5o 


b (external  form  of  n kst  max  offset) 
t.ACLjc'TIGNb 

ur.useo  segno  (procuio , segno); 
unuetineo  access  (procuio  , segno); 
oLx\lv  AI ICM  n kst  max  offset  (procuio , segno); 

vtoj  n kst  r.',ooe  (prccuio ; segno)  ->  mooe; 

i (returns  access  mooe  to  segment  tor  process) 
nluLon ; 

I^ITIALLI  mooe  = ?; 

v run  Kst  r..oue  (segno)  ( prccuic]  ->  mooe; 

:?  (external  fcr.i.  of  n kst  raouc) 

llo  l'<  d 

unusec  segno (procuic , segno); 
unaetinec  access ( or ocuic , segnc); 
uoRIVAi ICA  n ksc  mooe (procuio , segno); 

vr'Ln  n xst  ro  (procuio;  segnc)  ->  ro; 

d (returns  ring  crockets  of  segment  for  process) 

n 1 l.  oli'i  ; 

1»»  1 i lALLi  ro  = ?; 

VrLa  KSt  r o ( segno ) l prccuio i ->  ro; 

4>  (external  form  of  n xst  ro) 

Lal L,r’i  lo^b 

unusea  segnc (prccuio  , segno); 
uncerineci  access  (procuio  , segno); 

Lt. r, I v m!  1 on  n kst  ro( procuio,  segno); 

voja  n kst  ci  (prccuio;  se^no)  ->  cl; 

> (returns  call  ii .miter  or  segment  for  process) 

lULOLA  ; 

I-.liluLLi  cl  = ?; 

vtui  kst  ci  ( segno  ) l prccuio  ] ->  cl; 

« (external  tor.;;  of  n kst  ci) 

c.Av.Lrfluio 

ur.useo  segno  ( procuic  , segno); 
unoefineu  access (procuio , segno); 
ooi\l  VAi  loo  n kst  ci  (procuic,  segno); 

ori.i  revoke  access  (voluio;  seguio ) [prccuid ] ; 

d (revokes  access  to  segment  from  all  processes 
forces  access  to  be  recomputed) 

EAoL  f'2  luiib 

unrr.ounteo  volume  (prccuio  , voluio); 

no  segment (procuio , voluio,  seguio)  ; 

write  r.ct  el  ioweo  ( procuio  , h_seg_  al  (seguio ) ) ; 

Etc oCTb 

tCEALL  prcc  I h proc_cxists (prcc)  ; 

(cOEALL  segno  I n jtst  seguio  (prcc,  segno)  = seguio 
‘n_K.st  access  oef  ir.eo  ( proc  , segno)  = tALSL); 


tw 


GFuu  cevose_vol_acct3s (voluic ; procuia); 

S (revokes  access  to  all  segments  on  a volume) 

Lrc  Lt'i  S 

tCbALL  seguiu  I n_seg  exists (voluic , seguic)  : 
tFFLCTS  OF  r evoke  access  ( vo  1 u io  , seguic,  procuia); 

Of  U.<  release  segno  (segno)  [procuicj  ; 
n>  (releases  a segment  number) 

ULt lb II lUnb 

segment  uic  seguic  lb  n kst  seguic ( procuic , segno); 
u aCLPT 1 ebb 

unuseu  segno ( procuia , segno); 

Lr  c ijC'ia 

'n  kst  seguic (procuia , segno)  = ?; 

n_wr i tealloweu (n  prcc  trustee (procuia) , h croc  al(prccuia) 
n seg  al ( seguic) ) => 
c.1  clC'IS  or  cnange  ctu  ctm.  ( seg uiu ) ; 

orui't  pur  ^.e  accrcss  space (p roc)  ; 

u (releases  all  segments  in  acuress  space  oi  process) 

L r r c O I b 

m\ALL  segno  I n kst  seguic  (prcc,  segno)  ~=  ? : 
urfcCib  or  release  segno(segno,  prcc); 

orb.  write  (segno;  onset;  wore)  ( procuic  ; ring]  ; 
v (writes  a wore  or  a segment) 

UuC  lull  iutij 

volume  uic  veluio  IS  n kst  voluic (procuic , segno); 
segment  uic  seguic  lb  n kst  seguic ( procuic , segno); 
quota  cell  uic  ccuic  lb  h seg  cc  (seguic); 
c A o L 'c  V I w L'*  S 

unuseu  segr.c  (procuic  , segno); 
unmountec_volume (procuic , voluic) ; 
no  segment (prccuid , voluic,  seguic); 
uncerinec  access (procuia , segno); 
no  write  permission (procuia , ring,  segno); 
out_oi  oounus ( procuic , segno,  offset); 
page  quota  overflow (acuia)  ; 

ir  r fcCib 

uFFLCTS  OF  write  seg(seguia,  offset,  wore); 

uVnj.i  reaa(segno;  of  f set )( procuia  ; ring]  ->  were; 

P(reaas  a word  from  a segment) 
ut.Fl  i'i  mows 

volume  uid  voluic  IS  n kst  voluic (procuic , segno); 
segment  uic  seguic  lb  n KSt  seg uic ( prccu ic , segne); 

U Ac  U t'i!  ICi  ib 

unusec  segno (procuic  , segno); 
unmountec  volume  ( prccuic  , voluic); 
nesegment (procuic  , voluic,  seguic); 
uncetineu  access (procuic , segno); 
nor eaepermission (procuia  , ring,  segno); 


out_ot  ccuncs ( procuic , segnc,  offset); 
hr FlCTS 

hrFLCTS_GF  r eaa_seg  ( p r ecu  ic  , seauiu,  offset) 

CVrL^  fetcn(segno;  of fset)  Iprocuid ; ring)  ->  wera; 
S(fetcnes  an  instruction  weru  from  a segment) 
Lhhiu  II IC11S 

volu»ie_uic  voiuia  IS  n KSt  veluio (procuic , s 
segment  uia  seguia  IS  n KSt  sr  guid  (crocuic , 
hA»_c,r  I IGSo 

unusea  segno  ( procu ia , segno ) ; 
unmcuntec  volume (procuic , veluio)  ; 
no_segment (procuic , veluia,  seguia); 
unaef  ir.ec_access  (procuiu , segno)  ; 
no_execute_permission (procuic , ring,  segno); 
out_of_oouncs (procuic,  segno,  offset); 
EFFECTS 

EFFhCTo _0F  reau_seg (erocuid , secuic,  offset) 


C*»U  iiUL  L Lc 


bd 


= wore; 


eg  no)  ; 
segnc ) ; 


= wore ; 


CnAPTun  XII 


HLSSAoE  SEdiibilTS 


t\  message  segment  is  a special  type  cf  segment  tnat  serves  as 
a container  ter  smaller  objects  celled  messages.  Originally, 
it  was  cnvisior.ee  tnat  a single  message  segment  could  hole 
messages  ot  various  access  levels.  This  was  to  be 
accompiisnea  by  estaolisning  a minimum;  and  maximum  access 
level  for  eacn  message  segment . i’essages  witnin  a given 
message  segment  couio  then  be  assignee,  distinct  access  levels 
witnin  tne  alloweo  access  range.  This,  in  fact,  is 
essentially  the  case  in  current  Kultics.  Unfortunately, 
nowever  , tnis  m.etnoc  of  snaring  a message  segment  amc.ng 
multiple  access  levels  produces  another  instance  cf  the  shared 
rinite  resource  proolem. . 

one-  approacn  nos  been  suggested  [Sen]  tnat  restricts  m.essagc 
segments  to  a single  access  level,  cut  provides  an  "acc  up" 
capability,  i.e.  allows  a process  to  act.  messages  to  message 
segments  ot  e^ual  cr  greater  access  levels.  Unfortunately, 
unuer  tnis  seneme,  a process  could  not,  in  general,  read 
messages  tnat  it  nao  adaec.  mis  would  create 
incompatibilities  in  a numcer  ci  message  segment  applications, 
nost  noticeably,  it  would  prohibit  certain  users  from  listing 
tneir  pending  uprmt  and  absentee  reouests.  01  course,  no 
users  wcuiu  oe  aiiectec  at  single  access  level  sites. 


It  would  appear  tnat  a mere  compatible  solution  (i 
supports  multiple  access  level  message  segments ) 
cum^e  r some  m.ecnani  sm 
among  uifierer.t  access 
g us tiiieu  witnin  tne 
acnieveo  outside  tne 
cirlicuity.  outside 
message  segment  couio 
ordinary  single  access 


e.  one  that 
requires  a 
for  partitioning  message  segment  space 
levels.  Sucn  a mecnanism  cannot  ce 
Kernel  since  the  same  efiect  can  be 
Kernel  without  substantially  greater 
tne  Kernel,  a multiple  access  level 
oe  simulated  using  a collection  of 
level  segments. 


as  yet,  no  decision  nas  been  reached  as  to  wnich  approacn  to 
pursue.  none  of  the  alternatives  seem  especially  pleasing, 
nc  specifications  for  message  sega.ents  are  prcvidec  at  tnis 
time . 


CHAPTER  XIII 


COfJCLUS  10  is' S 


inis  report  has  presentca  a formal  top-level  specification  for 
a riultics  security  Kernel.  The  specification  has  teen 
analy zee  ires  tne  standpoint  of  security  as  oefir.ee  by  a 
matneiaat  icai  monel  ano  also  rrem  tne  standpoint  cf 
compatibility  witn  tne  current  hultics. 

*vitn  respect  to  security,  a number  of  specific  problems  have 
seen  identified.  .-lost  cf  tnese  are  instances  of  the  snares 
unite  resource  prcclem.  Altncugn  solutions  to  these  problems 
are  Known,  tney  often  yield  awkward  or  incompatible  interfaces 
ano  sometimes  require  excessive  mechanism  to  implement.  In 
some  cases , all  Known  alternatives  have  distinct  disadvantages 
ano  subjective  cncices  must  oe  made. 

compatibility  witn  current  .lultics  can  be  achieved  in  mest, 
out  not  all,  aspects  cf  the  kernel  interface.  A nur.cer  of 
ificompaticilities  nave  teen  introduced  for  reasons  of 
security.  vnese  incom.paticilities  are  significant,  tut 
nopefully  toieraoie  in  an  environment  where  security  is  the 
icremost  objective.  Also,  another  category  cf 
mcompatioilicies  nave  teen  introduced  to  promote  simplicity 
ano  tnerecy  facilitate  tne  proof  of  security  properties, 
inese  incompatibilities  can  ce  eliminated  at  a cost  of 
increased  verification  uitiiculty. 

Ine  formal  specifications  presentee  nerc  represent  only  an 
initial  effort.  Tney  are  not  yet  complete  nor  fully  refined, 
nowever,  tnis  iirst  step  nas  oeen  generally  encouraging.  The 
specification  technique  has  proved  helpful  in  illuminating  a 
variety  or  issues.  Tne  remaining  proclems  now  see  r.  / 1 1 i c c.  o t f 
specific  ar.o  well  understood.  Ever,  without  further 
enhancement,  tne  top-level  specification  presentee  nerc  should 
serve  as  a useful  guice  fo.r  related  work  in  proving  security 
properties  ano  developing  lower  level  Kernel  specifications. 
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APPcnDlX  A 


Air  force  Llectrcr.ic  systems  Division  Coinr.cn ts 


central  - Tne  report  is  not  complete.  many  areas  of  tne 
oesigr.  are  cmitteo  sucn  as  message  segments,  external  I/O, 
recent iguration,  utilization,  anc  "trustee  suoject" 
interlaces.  opecitic  ocsign  oecisions  are  avoicco  in  certain 
areas,  most  nctaoiy  various  instances  ot  tne  "finite  resource 
problem".  most  ot  tne  omissions  are  explicitly  ackncwlecged 
in  tne  report. 


rage  1,  line  -2.  (2no  line  iron,  bottom  of  page), 
monitor  is  not  restricted  to  enforcing  rules  of 
secur 1 ty  system . 


Tne  reference 
t h c military 


rage  line  +iu  Uotn  line  from  toe  of  page).  In  tne  ESD 
security  literature,  "vernicc"  ar.u  "ocrtilico"  nave  had 
distinct  meanings  ar.u  ore  r.ot  inter cnangeaoie . Verification 
is  a tecnnicai  activity;  certification  is  an  acministr ative 


action  available  only  to  a oesignateo  autnerity. 
pro vices  partial  gustirication  for 


,-er  i f ica  tion 


rage  i. , line  -a.  Some  mention  o.  tne  relative  priority  of 
access  ccr.trci  vs.  usability /compatibility  is  nceaed . 

rage  j,  iinc  +io.  Tne  pnysicai  size  oi  tne  Kernel  is  not  the 
reai  issue,  ratner,  it  is  the  number  ano  complexity  of 
speciiieo  functions. 


rage  j,  line  -r ^ . ins  discussion  coes  net  explicitly  acoress 
tne  isolation  oi  Kernel  processes. 


rage  s,  line  -lo 
sptcifieo  at  tne 
u s special . 


Ine  ‘‘special  interlaces"  either 
top  icvei  or  snouio  ce  explicitly 


need  net  sc 
iuentii ica 


rage  h , line  +o  . 


.■.essage  segments  nave  been  emitted  also. 


rage  o , 1 ir.e  +lb  . 
a surrogate  for  a 


ine  mcoel  coes  net  state  tnat  a subject 
user,  which  is  not  always  tne  case. 


is 


rage  d,  iine  -lb.  Ine  notion  ot  a visibility  access  level  is 
not  explicitly  ir.cluoeo  in  tne  current  matnematical  model. 

..ce  need  tor  a revised  ...cool  snouio  be  aocresseci.  It  qocs  net 
appear  tnat  tne  access  level  oi  tne  creator  ot  an  object  coulo 
outer  from  tne  visibility  access  level  ot  tne  object. 


rage  o , 
"sim.pler 
Objects  •• 


line  -t-id.  Tne  na 
representation  ci 
snouio  oe  oescribed 


ture  ot  the  Kernel 
the  access  matrix 
in  mere  detail. 


maintained 
tor  segment 
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ArPLiJuXX  a 


Air  force  uiectrcr.ic  systems  Division  Comments 


oeneral  - Tne  report  is  not  complete.  many  areas  of  tne 
oesigr.  are  emitted  suen  as  message  segments,  external  I/O, 
reconfiguration,  utilization,  anc  "trustee  sucject" 
interlaces.  upecnic  design  decisions  are  avoicec  in  certain 
areas,  most  nctaoly  various  instances  ot  tne  "finite  resource 
proolem".  most  or  tne  omissions  are  explicitly  acknowledged 
in  tne  report. 


rage  1,  line  -2  (2nd  line  iron;  bottom,  of  page), 
monitor  is  not  restricted  to  enforcing  rules  of 
security  system.. 


Tne  reference 
the  military 


rage  c , iir.e  + iu  (lutn  line  from  top  of  page).  In  the  ECD 
security  literature,  "verified”  and  "certified"  nave  had 
distinct  meanings  and  are  not  inter cnangeaoie . Verification 
is  a tecnnical  activity;  certification  is  an  administrative 
action  available  only  to  a designated  autr.crity.  Verification 
provides  partial  justification  for  certification. 


rage  r,  line  -o.  Seme  mention  of  tne  relative  priority  cf 
access  contrci  vs.  usabiiity/com.patibility  is  nceaeo. 


rage  3,  line  +iu.  Tne  pnysicai  size  oi  tne  Kernel  is  not  the 
real  issue,  ratner,  it  is  the  number  anu  complexity  of 
speci i ieo  functions . 


rage  j , iir.e  -22.  ins  discussion  aoes  net  explicitly  address 
tne  isolation  oi  Kernel  processes. 


t age  3,  line  -lo.  Tne  "special  interlaces”  either  reed  not  be 
specified  at  tne  top  level  cr  snouio  ce  explicitly  identified 

c.  S SCCCiai  • 


rage  4 / line  +o. 


message  segments  nave  been  emitted  also. 


rage  o,  line  +14.  Tne  mcoel  cces  not  state  tnat  a subject  is 
a surrogate  for  a user,  wnicn  is  not  always  tne  case. 

Tage  o,  iine  -13.  Tne  notion  ot  a visibility  access  level  is 
not  explicitly  included  in  tne  current  matnematiccl  model . 

iiie  need  ter  a revised  mcoel  snouio  be  aocressea.  It  aoes  net 
appear  tnat  tne  access  level  ci  tne  creator  ct  an  object  could 
differ  from  tne  visitility  access  level  ot  tne  object. 

rage  o,  line  +i3.  Tne  nature  of  the  Kernel  n.iintainca 
"simpler  representation  ci  the  access  matrix  ter  segment 
oojects"  should  ue  described  in  more  detail. 


Page  o , line  -lb.  'inc-  thirc  approach  ler  handling  finite 
resources  fitters  from  tne  otner  two  in  tnat  it  is  a mechanism 
retner  tnar.  policy.  ine  trustee  process  coulo  enforce  eitner 
tne  quota  per  level  or  tne  time-multiplexing  method.  An 
alternative  tniru  policy  coulo  he  to  provioe  auoit  and 
surveillance  tools  to  report  requests  for  resources  in  excess 
ot  tnat  avaiiaole  so  tr.at  juagment  can  be  made  and  action 
taxer,  ii  it  appears  that  users  are  circumventing  security 
controls  tnrougn  finite  resource  limitations.  Actions  tnat 
coulo  oe  ur.oertaxen  externally  induce  acting  new  resourews  to 
tne  system,  freeing  usee  resources  or  denying  furtner  system 
access  to  a requestor  suspectco  of  attempting  to  circumvent 
tne  security  controls. 

t'age  ih,  line  1j.  Tne  omission  of  exectior.s  for  internal 
runctions  ccuio  eriect  verification.  Certain  constraints  must 
oe  satisrieo  in  oroer  for  tne  function  to  produce  its  effects. 
Ine  exception  conoitions  of  referencing  functions  rust  insure 
one  constraints  arc  satisfiec. 

rage  is,  line  +17.  Ine  rationale  for  nioir.g  some  u arm  CV 
rur.ctions  is  not  apparent. 

+ age  iu,  aovar.ee  cIock.  Tne  use  of  tnis  function  is  net 
apparcr.c.  It  seems  tnat  tnis  function  need  (would  not  be 
avaiiaole  at  tne  kernel  interface.  .Tore  natural  alternatives 
may  be:  (i)  induce  changing  tne  value  of  tne  clock  in  a 
specification  of  tne  instruction  fetch  cycle  (ilcte  tnat  the 
increment  woulo  oe  arbitrary  for  may  "kernel  instructions"), 
(d  nave  get  uic  upcate  tne  cIock  (im.piics  tne  value  ot 
reaw  ciccx  is  only  cnanged  by  calls  to  get  uic)  ar.c  (3)  chance 
tne  specification  of  reac  cloc.\  to  show  tnat  the  dock  and 
kernel  processes  operate  asyncnrcncusly  (seems  to  oe  the  most 
realistic).  tor  example,  tne  specification  cculc  merely  state 
tnat  time  > 'time  (or  time  > ‘time  if  tne  granularity  of  tne 
ciocx  was  liner  tnar,  tne  time  requires  tc  oc  the  read 
operation) . 

+ age  , celcte  ptcc.  Please  provide  tne  rationale  for  not 
allowing  a process  to  oeietc  itself. 

rage  d,  wake.  It  is  not  dear  why  tnis  function  exists  since 
only  waxeup  uses  it. 

i-age  he,  line  -** . Tnis  oiscussior.  ooes  not  consider  the 
time-multiplexing  aeproaen  tc  solving  tne  problem.  If  every 
user  nao  to  mount  (a  virtual  mount)  a volume  before  the  volume 
was  references,  tnere  woulu  oe  no  storage  channels. 

Irage  Jo,  create  volume.  Ine  initial  quota  for  every  volume  is 

always  a constant.  Inis  occ-s  net  seem  appropriate  because  tne 
volume  may  consist  of  a variaoie  number  ot  physical  seconcary 


05 


storage  ue vices  a no  arbitrary 
unusable . 


areas  of  some  devices  may  be 


rage  33,  line  -17.  Tne  restriction  against  moving  quota 
oownwaru  will  cause  quota  to  be  lost  when  upgraued,  terminal 
segments  are  celeteo.  Deleting  terminal  segments  snculc  get 
quota  oack  to  its  original  level.  This  is  a deficiency  in  the 
"ueiete_seg"  function.  Cuotat  on  an  upgraded  segment  is  lost 


wnen 

tne 

segment  is 

celeted . 

rage 

3o  , 

iir.e  -ib. 

As  I"1  C t G C / 8 

me  t nod  tor 

controlling  tne 

number  of 

quota  cells  is  needec. 

rage 

14  , 

iine  - i o . 

A tnir a incom 

patio ility 

was  noted 

in  the 

comments 

on  tne  previous  page. 

rage 

bi  / 

i ino  1^. 

As  noted,  nere 

is  another 

unsol veu 

r inite 

resource 

preuiem . 

rage 

4 i , 

iir.e  -a. 

bore  internal 

C 8 Cj  0 s ccuic. 

be  handled 

by  a 

"iree"  lunocior.  as 

well  as  t rune a 

tc . 

rage 

40  , 

iine  +16  . 

Incorporation 

of  otu  ano 

utm  in  the 

kernel 

snoui 

u ue 

jus t if ieu 

• 

r a 9 C 

bO  , 

r An  A.  .l.  1 

ui.u . Tne 

specification  implie 

s the 

inaxcf  tset , .tax  pageno  ano  page_sicc  are  ail  indepenoent.  It 
seems  tnat  one  snoule  ue  tnc  function  or  tne  other  two. 

rage  47.  Tne  function  parameters  seem  inconsistent.  Some 
tunctions  neve  cctn  vciuiu  ar.u  seguio  as  parameters  while 
otners  nave  only  seguic.  Please  explain. 

rage  ol , line  -o . Tne  need  tor  rc-vcke_vol  access  is  rot 
ciear.  Tne  revcke_scg  access  will  hancle  tne  example  giver.. 

rage  ju,  give_acccss.  Since  offset  is  a parameter,  two 
processes  may  snare  parts  of  a segment.  It  seems  this  may 
complicate  tne  management  oi  page  tables.  Tne  justification 
ter  prcvioing  this  capability  wculu  be  helpful. 


rage  ou,  iine  -3. 


As  noteo  message  segments  are  missing. 


o o 
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MISSION 
OF  THE 

DIRECTORATE  OF  COMPUTER  SYSTEMS  ENGINEERING 


The  Directorate  of  Computer  Systems  Engineering 
provides  ESD  with  technical  services  on  matters 
involving  computer  technology  to  help  ESD  system 
development  and  acquisition  offices  exploit  computer 
technology  through  engineering  application  to  enhance 
Air  Force  systems  and  to  develop  guidance  to  minimize 
R&D  and  investment  costs  in  the  application  of  computer 
technology. 

The  Directorate  of  Computer  Systems  Engineering 
also  supports  AFSC  to  insure  the  transfer  of  computer 
technology  and  information  throughout  the  Command, 
including  maintaining  an  overview  of  all  matters  pertain- 
ing to  the  development,  acquisition,  and  use  of  computer 
resources  in  systems  in  all  Divisions,  Centers  and 
Laboratories  and  providing  AFSC  'with  a corporate 
memory  for  all  problems /solutions  and  developing 
recommendations  for  RDT&E  programs  and  changes  in 
management  policies  to  insure  such  problems  do  net 
reoccur. 
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